Geekstammtisch

Wir sprachen mit Mario Heiderich über (Web-)Security Unser Gast (00:00:00)

• Mario Heiderich, @0x6D6172696F
• Hat einen Security Talk "Im DOM hört Dich keiner schreien" auf der enterJS gegeben: http://www.enterjs.de/
• Mario's Security Firma: https://cure53.de/
  • Nutzen wenig Scanner, mehr Handarbeit
• Security Scanner finden keine "logischen Bugs"
• RIPS: Statische Analyse von PHP Code: http://rips-scanner.sourceforge.net/

• Sources: Quellen von Input (User Input z.B.)
• Sink: Stellen im Code, wo Input ankommt bzw. was mit ihm passiert
• Input: Input :)
• Getestet wird manchmal in VMs, manchmal auf Test oder Staging Umgebungen oder auch in Produktion
  • das hängt vom Kunden und Projekt ab
• WAF: Web Application Firewall: https://en.wikipedia.org/wiki/Application_firewall
• Erfolgsquote: 100% - "noch keine leeren Reports"
• Eine Frage der Einstellung: Die einen Entwickler wollen Features bauen, andere Software kaputt machen
• Scope
  • "Ihr dürft nicht nach DoS suchen!"
  • Abgrenzung, was in der Betrachtung liegt und was nicht
• Vektor: Der Angriff an sich, z.B. ein String bei einer SQL Injection; oder Vektor kann ein ganzer Prozess oder Ablauf sein
• Exploit: Nutzung eines Vektors mit einem Ziel: Beispiel String (Source) für SQL Injection (Vektor) nutzen, um Admin zu werden
• Pwn2Own: https://en.wikipedia.org/wiki/Pwn2Own
• Stuxnet: https://en.wikipedia.org/wiki/Stuxnet

• Marios Firma hat für alle möglichen Bereiche Spezialisten:
  • Binary Pentesting
  • Datenbanken
  • Web/Browser/JavaScript/Flash
  • Bruteforcing
  • Cold Fusion
  • Kryptographie, Kryptoanalyse
  • Java

• Es verlagert sich viel in den Browser
• daher mehr und mehr Lücken in Richtung XSS, CSRF, …
• NoSQL wird auch getestet
• MongoDB führt JS in der Datenbank aus und zwar als eval!

• "Nennt sich doch mal constructor.constructor"
  • oder "prototype"
  • "proto"

• Validieren: Format explizit und strikt prüfen
• Filtern: z.B. Single Quotes oder Kommata entfernen
• Aber so einfach ist das nicht
  • Strings (Quotes) verboten? was ist mit /i'm a string/.source
  • 1..constructor.constructor
• Sanitizing:
  • "Escape den Input und Encode den Output"
  • Es ist wichtig zu unterscheiden zwischen der Information die durch das Sanitizing soll, UND
  • Kontext, wo die Information später verwendet werden soll

• Template Expressions Exploit, z.B. bei AngularJS: https://code.google.com/p/mustache-security/wiki/AngularJS
• Der Browser ist die neue Sink
• Security im Browser ist anders und komplexer als auf dem Server
• Sehr viel mehr Wissen über konkrete Prozesse bei der Darstellung von HTML/CSS und der Ausführung von Javascript notwendig
• Browser ist im Grunde "moving target"
• Die Vielzahl der Browser bietet sehr viel Angriffsfläche
• Vor allem im Kontext großer Unternehmen sind oft auch sehr alte Browser noch im Einsatz (IE6)
• Eine Umstellung auf neuere Browser ist u.U. nicht immer möglich => Paradies für Pentesting

• Talk auf der enter.js (http://www.enterjs.de/abstracts#im-dom-hoert-dich-keiner-schreien-eine-reise-in-die-gruselige-schicht-zwischen-html-und-javascript)
• Historie des DOMs
• Verschiedene Probleme aufgezeigt, Bsp.: DOM-Clobbering
  • Mit statischem HTML bestehende Variablen, Funktionen o.ä. überschreiben
  • Ist im Grunde im Standard sogar definiertes Verhalten oO
• Am Ende kann man sehr viel Spaß nur mit statischem HTML haben :-)
• Was ist das DOM überhaupt
  • Ein API zwischen einem Dokument und einer beliebigen Scripting-Sprache
  • Ziel des DOM: Bereitstellung von Feature-Parität, dabei müssen einige Features explizit ausgeschlossen werden
  • Bsp: CSS-History-Stealing (http://jeremiahgrossman.blogspot.de/2006/08/i-know-where-youve-been.html)
• SVG bringt möglicherweise ganz neue Probleme mit
  • Timing Attacke von Paul Stone mit Hilfe von SVG Filtern: http://www.contextis.com/documents/2/BrowserTimingAttacks.pdf
• Manchmal gibt es auch keinen echten Fix für Lücken, und selbst wenn, es gibt ja jetzt auch CSS Shader ;-)
• Wie geht man vor um Lücken zu finden
  • Viel Kreativität notwendig
  • Man hört von einem Feature und denkt sich, da muss doch was gehen und dann wird halt so lange gebohrt bis man was findet ;-)
• DOMPurify (https://github.com/cure53/DOMPurify) ist ein Client-seitiger Sanitzer, um verschiedenen Angriffen zu begegnen
• Reaktion auf der Konferenz war vor allem gefasst :-)

• Grundsätzlich: Bedarf steigt an, Verbreitung nimmt zu
• Man hört immer wieder von Problemen
• Was kann man machen?
• Antwort: "Ich habe keine Ahnung"
• Aussage Mario: Wir sind noch nicht soweit, es zuverlässig einzusetzen.
• Aber: Es ist auch nicht zum Scheitern verurteilt, aber es braucht noch einiges an Research
• Seiten wie https://keybase.io machen das bereits
  • Kann man machen, wenn die Seite 100% sicher und vor allem beweisbar sicher ist
  • Ergo: Aufwand ist enorm hoch
• Es gibt auch Bestrebungen vom W3C das Thema voranzutreiben: http://www.w3.org/TR/WebCryptoAPI/
• Zusätzlich entstehen ganz neue APIs für den Zugriff auf mobile Devices
  • Bsp: Android-Devices haben über nicht hörbare Töne miteinander kommuniziert
  • Exploits mit Sprachsynthese und Spracherkennung (Bsp: Cookies zwischen Tabs übertragen)
• WebGL klingt kritisch, aber in dem Bereich gibt es in den letzten Jahren viel Forschung
• WebSockets und WebRTC bietet hingegen auch viele Möglichkeiten