ONE Conference: Vulnerabilities in Web Applications
Download as KEY, PDF0 likes695 views
Vulnerabilities in Web Applications discusses common security risks for web applications. It summarizes a study showing that over 60% of cyber attacks target web applications. The document recommends following standards like PCI-DSS and OWASP to integrate security into the software development lifecycle. It also describes how Anonymous hackers exploited SQL injection and password reuse vulnerabilities to compromise HBGary Federal's systems and steal internal data, bringing the company down. The key lessons are that security must be a priority from design through maintenance, and that even small vulnerabilities can have major consequences if not addressed.
ONE Conference: Vulnerabilities in Web Applications
- 1. Vulnerabilities in Web Applications Simon Dietschi, Netcetera AG
- 2. Why care about (web application) security?
- 3. Sources of risks experienced by organizations sampled in the USA (2011) Viruses, worms, trojans Malware Botnets Web attacks Stolen devices Malicious code Malicious insiders Phishing Denial of service 0 25 50 75 100 Ponemon Institute© Research Report, SANS Cyber Security Risks, Web-Hacking-Incident-Database
- 4. Motivation • Wake-up call for security awareness • Security as a topic critical to the success of an information system • Insecure web applications in financial, healthcare, power, defense, aviation and other critical infrastructures • More than 60% of all cyber attacks against web applications
- 7. PCI-DSS Payment card industry data security standard
- 8. PCI-DSS in practice • Designed for the payment card industry • Too heavy for projects without the need to be PCI certified • PCI requirements only define the different processes that have to be in place • Does not define how the processes have to be implemented, only the expected outcomes
- 9. What can we take from PCI-DSS?
- 10. Requirement 6 • Ensure that all system components and software are patched from known vulnerabilities • Incorporate information security throughout the software lifecycle • Develop applications based on secure coding guidelines, prevent coding vulnerabilities during development • In production, address new threads and vulnerabilities on an ongoing basis
- 11. OWASP Open web application security project
- 12. What can we take from OWASP?
- 13. OWASP Top 10 • List of top 10 most critical web application security risks • Covers likelihood and consequence factors, severity • Good start point for developers, designers, architects and organizations
- 14. OWASP ASVS • Application Security Verification Standard • Concrete approach for verification of web application security and integration into existing software lifecycle • Level based coverage, customizable depending on the project needs • Approach to become a commercially-workable open standard
- 16. SDLC Secure Software Development Lifecycle
- 17. Testing, QA, Analysis Design Development Production Acceptance
- 18. Define application security requirements by risk level Testing, QA, Analysis Design Development Production Acceptance
- 19. Define application Plan how to security meet security requirements by requirements risk level Testing, QA, Analysis Design Development Production Acceptance
- 20. Define application Plan how to Implement security meet security secure requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
- 21. Define application Plan how to Implement Verify security security meet security secure requirements requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
- 22. Define application Plan how to Implement Verify security Fix findings security meet security secure requirements requirements by requirements architecture risk level Testing, QA, Analysis Design Development Production Acceptance
- 23. So now we are done?
- 24. Ongoing Security • Policies, guidelines • Education, security training, principles, best practices • Design reviews, code reviews, security testing • Vulnerability management, environment hardening
- 25. Security V.S. Business needs • Management: “Use remaining project budget for security...” • Security often seen as too expensive and therefore disregarded within a project • Security is a hidden business need too, but who has to pay for it ? • Solution: Integrate security into business needs
- 26. HBGary Hack
- 27. HBGary V.S. Anonymous • HBGary Federal: • Security company • Provides information security solutions to U.S. government • CEO: Allen Barr
- 28. HBGary V.S. Anonymous • Anonymous:
- 29. 1. Step: SQL-Injection • Custom CMS by third-party company used for hbgaryfederal.com • SQL-Injection over URL was possible: http://www.hbgaryfederal.com/pages.php?pageNav=2&page=27 …pages.php?pageNav=2&page=27;update users set passwd=‘1234’ where username=‘admin’; Code: title=SQL(“select title from page where pageid= $url_param(page)”);
- 30. What happened? • Anonymous successfully reseted CMS Admin account • Anonymous took list of usernames, emails, passwords from CMS DB • Password encryption was not strong enough • Anonymous retrieved passwords from HBGary CEO and COO • Responsible at the company that implemented the CMS - fired
- 31. Lessons learned • For developers: be aware of SQL-Injection and use salts for password hashes • Enforce sufficient password complexity • Be aware of security, especially if custom or third party software is being used
- 32. 2. Step: attacking the support server • Password of the COO allowed to remote log into the support server (support.hbgary.com) • Linux with unpatched vulnerability allowed to become root
- 33. What happened? • Several backup and research data has been stolen by Anonymous • Backup data was deleted by Anonymous
- 34. Lessons learned • Reuse of passwords is very bad • Do not keep sensitive data on servers faced to the internet • Patching known vulnerabilities is very important
- 35. 3. Step: Compromising Email accounts • Google Apps was used by HBGary Federal as email services • The CEO and COO passwords worked there as well • The CEO account had admin privileges
- 36. What happened? • Anonymous locked out HBGary from any email access • Anonymous published over 68k of company emails on the internet • Publication included reputation destructive, internal content
- 37. HBGary Hack • Anonymous did some social engineering too • But finally, they brought down HBGary (28. February 2011)
- 38. Conclusion • Well known and easy to detect SQL-Injection vulnerability was the root cause • Security is very important, for software, systems and persons • Vulnerabilities can damage reputation or bring down a whole company
- 39. To take home • Security is not a skill, it is a mindset • Build security into a web application’s architecture from the start • Keep information security an ongoing and evolving process
- 40. Thanks, and stay secure
Editor's Notes
- #2: Herzlich Willkommen zur Präsentation “Schwachstellen in Webapplikationen”.\n\nDoch bevor wir loslegen, warum stehe ich heute vor ihnen? Ist es weil ich als technischer Projektleiter im Card & Payment Services Umfeld und als Sicherheitsexperte bei Netcetera mit dem Thema Security zu tun habe? Ja und nein - spätestens am Ende meines Vortrages hoffe ich, ihnen diese Frage beantwortet zu haben und falls nicht: Nach dem Vortrag stehe ich gerne für Feedback und Fragen im Bistro in der Meeting-Zone zur verfügung.\n
- #3: Warum ist Sicherheit in Webapplikationen so wichtig?\n\nSchauen wir uns dazu einleitend folgende Statistik an\n
- #4: 2011 hat man in den USA bei ausgewählten Unternehmen ermittelt, durch welche Risiken sie das ganze Jahr durch wie oft betroffen waren.\n\nDas Resultat ist eindeutig: Wenn wir uns die 4 Top-Risiko-Gruppen, Virus/Würmer/Trojaner, Malvare pot net und natürlich Web Attacken anschauen, lassen sich daraus zwei Angriffsziele ermitteln: \n\n1. Die Client- oder Anwender-Seite, wo die Verwendung von älterer Software Sicherheitslücken mit sich bringen kann, und\n\n2. Webapplikationen, welche vom Internet aus erreichbar sind\n
- #5: Meine und hoffentlich auch ihre MOTIVATION:\n\nWebapplikationen mit Schwachstellen findet man überall, ob Bankenumfeld, Versicherungen, Gesundheitswesen, Energieversorgung, Verteidigung oder Staat - vor allem kritische Umgebungen sind davon betroffen.\n\nUnd wenn man bedenkt, dass ca. 60% aller Cyber-Angriffe auf Webapplikationen statt finden ist das definitiv eine Motivation.\n\nHinzu kommt noch, dass Informationssicherheit ein klarer Erfolgsfaktor ist für Unternehmen.\n
- #6: Wo fangen wir an?\n
- #7: Standards, Prinzipien, Guidelines - oder was wir von PCI-DSS und OWASP übernehmen können\n
- #8: PCI-DSS\n
- #9: PCI-DSS hat sich als Sicherheitsstandard in der Kartenindustrie etabliert, allerdings ist er aufgrund seines Umfanges an Anforderungen für nicht PCI-Projekte ungeeignet:\n\n=> Die Umsetzung bis hin zur Zertifizierung ist teuer, je nach Grössenordnung sind dies schnell mal um die 70’000 Franken.\n\nWichtig ist auch, dass PCI-DSS nur die Prozesse vorschreibt, welche etabliert sein müssen. Es wird aber im Detail nicht weiter darauf eingegangen, wie diese Prozesse zu implementieren sind.\nMan ist also frei bei der Wahl von geeigneten Sicherheits-Framework.\n
- #10: Was können wir von PCI-DSS mitnehmen?\n
- #11: Aus den 12 Hauptanforderungen ist das Requirement 6 am interessantesten:\n\n- Sicherheits-Patching von Systemen und Applikationen\n- Einschätzung und Vorgehen bei neu entdeckten Risiken\n- Integration der Informations-Sicherheit in den Software-Lebenszyklus\n- Sicheres Entwickeln von Software\n\n...dies sind im Wesentlichen die Themen zu denen das Requirement 6 die Etablierung von entsprechenden Prozessen beschreibt.\n
- #12: PCI-DSS und das Requirement 6 bilden das Gerüst, nun brauchen wir noch einen Inhalt.\n\nWie wir gesehen haben, ist es einem bei PCI selbst überlassen, welche Sicherheits-Frameworks oder Standards man für die Umsetzung verwenden möchte.\n\nIch habe mich hier für OWASP entschieden.\n
- #13: Welche Frameworks können wir aus OWASP verwenden?\n
- #14: OWASP Top 10 ist viel mehr als nur eine einfache Liste der 10 kritischsten Sicherheits-Risiken für Web Applikationen.\n\nSie enthält für jeden der 10 Punkte viele nützliche Informationen: \n- Angriffsvektoren\n- Schwachstellen\n- Risiko-Einschätzungen\n- Auswirkungen auf geschäftlicher und technischer Ebene\n- Praxis-Beispiele und vieles mehr.\n\nÜbrigens bauen auch die meisten OWASP Sicherheits-Standards auf OWASP Top 10 auf.\n\nFür Entwickler, Designer, Architekten und auch für Manager ein guter Start-Punkt!\n
- #15: Mit PCI-DSS und Requirement 6 haben wir eine Antwort auf die Frage, was wir tun wollen. Jetzt müssen wir noch das WIE beantworten.\n\nDer OWASP application security verification standard eignet sich besonders gut, da man mit ihm dynamisch und abhängig von den Bedürfnissen und vor allem der Grösse eines Projektes, Sicherheits-Anforderungen ermitteln, festlegen, prüfen und verifizieren kann.\n\nWie wir etwas später noch sehen werden, lässt sich ASVS auch sehr gut in den bestehenden Entwicklungs-Zyklus integrieren und folgt dem Ansatz, ein offener Standard zu sein.\n\n\n
- #16: Massnahmen und Vorbeugung\n
- #17: Das Herzstück eines Software Projektes ist der Software Lebens-Zyklus. Gleichzeitig ist er aber auch der Ursprung für die Entstehung von Sicherheitslücken und Schwachstellen.\n\nAnhand des nachfolgenden Beispiels möchte ich ihnen zeigen, wie ein Secure Software Development Lifecycle aussehen könnte.\n
- #18: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #19: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #20: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #21: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #22: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #23: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #24: [1]\nSchon während der Anaylse-Phase legt man Sicherheits-Anforderungen anhand der Anforderungen an die Web Applikation fest.\n\n[2]\nIn der Design-Phase geht es dann darum, festzulegen wie man die Sicherheits-Anforderungen erfüllen kann. Es geht vom nicht technischen in den technischen Bereich.\n\n[3]\nWährend der iterativen Entwicklungs-, Testing- und QA- Phase wird eine sichere Architektur implementiert.\n\n[4]\nDabei entscheidend ist ständig zu prüfen, ob die Sicherheits-Anforderungen eingehalten wurden.\n\n[5]\nWie bei den Iterationen in einem Agile-Projekt, gibt es für die Behebung von gefundenen Sicherheits-Risiken und der erneuten Verifikation ebenfalls eine oder mehrere Iterationen.\n\nIn der Theorie so lange bis alle gefundenen Sicherheits-Risiken noch vor dem Go-Life behoben sind.\n
- #25: Wars das schon?\n
- #26: Neben dem sicheren Software Entwicklungs-Zyklus ist auch mittelfristig die kontinuierliche Weiterentwicklung der Security als Ganzes entscheidend.\n\nDazu gehören:\n\n- Richtlinien für Entwickler\n- Aus- und Weiterbildung, Training, Praxis\n- Design-, Architektur- und Secure Coding Reviews\n- Security-testing, Penetrations-testing\n- Risiko-Management\n- Härten von Umgebungen mittels Standards\n\nDas Ziel ist nicht, ein geschlossenes Team von Sicherheits-Experten zu haben. Viel mehr geht es darum, Sicherheits-Themen in die tägliche Arbeit so zu integrieren, dass jegliche Reviews früher oder später fast schon langweilig sind.\n
- #27: Bevor wir in wenigen Minuten zum Showcase übergehen, noch ein paar Punkte zu Security versus Geschäfts-Anforderungen:\n\n“Verwendet das übrig bleibende Projekt-Budget für die Security”, höre ich in der Praxis von Managern zum Thema.\n\nUnd vom Auftraggeber aus gesehen wird Sicherheit als Selbstverständlichkeit angesehen, man könnte also sagen Sicherheit ist ein verstecktes Business-Requirement.\n\nSecurity muss von Beginn an in die Geschäfts-Anforderungen und in die Offerte eines Projektes miteinfliessen.\n
- #28: Kommen wir zu einem Show Case - der HBGary Hack\n
- #29: Es war einmal eine renomierte US-amerikanische Security-Firma, die zum grössten Teil Sicherheits-Lösungen für die amerikanische Regierung entwickelte.\n\nDer damalige CEO war Allen Barr, der um jeden Preis das Gesicht von Anonymous aufdecken wollte...\n
- #30: Genauer gesagt war er überzeugt, Namen und Adressen von Schlüsselpersonen bei den “NAMENLOSEN” aufgedeckt zu haben.\n\nAllen Barr behauptete auch zu wissen, wer bei ANONYMOUS für die damaligen Angriffe auf Visa und MasterCard verantwortlich war.\n\n
- #31: ANONYMOUS liess sich dies nicht gefallen und startete einen Hacker-Angriff gegen HBGary.\n\nUnter Ausnutzung einer Schwachstelle im Content Management System, welches übrigens von einer Dritt-Firma kam, gelang Anonymous eine SQL-Injection.\n
- #32: Was war passiert?\n\nAnonymous hatte das Administrator-Passwort zurückgesetzt und Benutzer-Daten aus der CMD Datenbank geklaut.\n\nDa die Verschlüsselung der Passwörter aus der DB zu schwach war, liessen sich die Passwörter rekonstruieren.\n\nDer Verantwortliche bei der Firma, die das CMS implementiert hat, wurde gefeuert\n
- #33: Was können wir daraus lernen?\n\n1. Punkt, für Entwickler: Unterschätzt klassische SQL-Injection nicht, und benutzt starke Verschlüsselung für gespeicherte Passwörter\n\n2. Punkt: Applikationen sollten eine genügende Passwort-Komplexität forcieren\n\n3. Punkt: Besonders beim Einsatz von Software von Dritt-Anbieter immer auch auf die Sicherheit achten\n
- #34: In einem zweiten Schritt nutzte Anonymous das entschlüsselte Passwort aus der CMS Datenbank für den Login auf dem Support-Server von HBGary.\n\nDank einer Linux-Version, bei der eine Sicherheitslücke nicht gepatched war, konnte Anonymous den Administrator-Benutzer kapern\n
- #35: Was war passiert?\n\nMit dem Administrator-Benutzer gelang es Anonymous bedeutende Forschungsdaten zu klauen und das Backup auf dem Server zu löschen.\n
- #36: Was können wir daraus lernen?\n\n1. Punkt: Die mehrfache Verwendung des selben Passwortes ist nicht nur für einen COO schlecht\n\n2. Punkt: Sensitive Daten, aber auch ein Backup, gehören nicht auf einen Server der direkt dem Internet exponiert ist\n\n3. Punkt: Patching von Sicherheitslücken ist extrem wichtig!\n
- #37: In einem dritten Schritt gelang es Anonymous die Email-Accounts von HBGary zu kompromitieren.\n\nGoogle Apps wurde firmenweit verwendet, und die beiden Passwörter des CEO und des COO funktionierten auch dort.\n\nDer Google-Account des CEO war zu gleich auch der Admin-Account.\n
- #38: Was war passiert?\n\nAnonymous sperrte der ganzen Firma die Email-Accounts und veröffentlichte ca. 68’000 Emails im Internet.\n\nDarunter waren auch Inhalte, die normalerweise nie ans Tageslicht gekommen wären.\n
- #39: Die Geschichte ging weiter, Anonymous ging zu Social-Engineering über, und am 28. Februar 2011 war HBGary offline.\n
- #40: Zusammenfassend hat uns der HBGary Hack folgendes gezeigt:\n\n1. Auch eine der bekanntesten Schwachstellen wie die SQL-Injection kann unerkannt grossen Schaden anrichten\n\n2. Sicherheit ist sehr wichtig, für Software, Systeme und Personen\n\n3. Schwachstellen können den Ruf einer Firma stark beschädigen oder sogar die ganze Firma zu Fall bringen\n
- #41: Zum Schluss, ein paar Punkte zum mitnehmen:\n\nSicherheit ist nicht einfach eine Fähigkeit, sie ist eine Denkweise und findet in unseren Köpfen statt.\n\nSicherheit sollte von Beginn an in die Architektur einer Web Applikation integriert werden.\n\nDie IT-Branche entwickelt sich in einem rasanten Tempo weiter. Sicherheits-Risiken verändern sich - Informations-Sicherheit muss ein sich ständig weiterentwickelder Prozess bleiben\n
- #42: Vielen Dank fürs Zuhören, und bleiben sie Sicher!\n