Testing Module Compass Security AG 14. January 2010

Transkript

1 Compass Security AG Glärnischstrasse 7 CH-8640 Rapperswil T F Testing Module Compass Security AG 14. January 2010 Name des Dokumentes: security_module_beschreibung_v1 1_deu.doc Version: v1.1 Autor(en): Ivan Buetler, Compass Security AG Cyrill Brunschwiler, Compass Security AG Lieferungsdatum: 14. Januar 2010 Klassifikation:

2 Inhaltsverzeichnis 1 SECURITY TESTING MODULES Einleitung Testing Modules Übersicht Implementation Testing Local Testing Remote Testing Network Testing DB Testing Application Security Testing Web Application Security Testing Checklisten Network Pentest Web Application Pentest Source Code Review Seite: 2

3 1 Security Testing Modules 1.1 Einleitung Bei der Durchführung von IT Security Penetration Tests, Audits und Security Assessments werden verschiedene Arbeiten und Aktivitäten durchgeführt, die in sogenannten Testing Modulen definiert sind. Die Arbeiten werden in Testing Module unterteilt, damit die verantwortlichen Stellen bei deren Durchführung ein gemeinsames Verständnis über den Inhalt und die Rahmenbedingungen haben. Das Ziel dieses Dokumentes ist es, zu erklären, welche Test Module definiert sind und was deren Inhalt und Zielsetzung ist. Dadurch soll die Arbeit zwischen dem Projektteam und der Sicherheitsabteilung abgestimmt werden. 1.2 Testing Modules Übersicht IT Security Testing Module Name Implementation Testing (Feature Check) Local Testing (Hardening Check) Remote Testing (Network Pentest) Network Testing (Topology Review) Beschreibung Prüfung von neuen Funktionalitäten und Features. Typischerweise wird dieses Testing Modul dort eingesetzt, wo ein wichtiges Update oder Feature installiert wird und die Gesamtsicherheit beeinflusst werden könnte. Beispielsweise eine neue Chat Anwendung im Business Portal oder die Erweiterung von Client Certificates bei der Authentisierung. Prüfung der lokalen Sicherheit eines Computer Systems wie z.b. einem Windows-, Linux-, Solaris-, AIX- oder anderen Servern. Dabei werden hauptsächlich das Hardening und die File- als auch Prozessrechte, wie auch die zum Betriebssystem gehörenden Services wie SSH etc. analysiert. Die Beurteilung von Zusatzprodukten auf dem OS wie beispielsweise ein Web Application Server sind in diesem Modul nicht enthalten. Prüfung der Zielsysteme bezüglich Netzwerkattacken aus dem gleichen und/oder einem fremden Netzwerksegment. Dazu gehört die Identifikation von Security Schwachstellen die durch Angreifer ausgenützt werden können, welche über keine Account Information auf dem Zielsystem verfügen. In diesem Testing Modul wird der klassische Penetration Test mit automatisierten Portscans, Fingerprinting und Vulnerability Scanning durchgeführt. Das Network Testing Modul analysiert die Einbindung des Zielsystems in die IT Landschaft. Der Fokus wird dabei auf das Zonenkonzept, Inside-Out Bedrohungen und Firewalling gelegt. Dieses Modul wird in enger Zusammenarbeit mit dem Netzwerk- und Firewall Team durchgeführt und auf Wunsch technische Untersuchungen anhand der Szenario Technik (was wäre wenn) definiert, priorisiert und durchgeführt. Das Ziel ist es, sämtliche Verbindungen vom und zum Zielsystem zu kennen und bezüglich Schwachstellen zu beurteilen. Seite: 3

4 IT Security Testing Module Name DB Testing (DB Access Hardening) Application Security Testing (Application Security Analysis) Web Application Security Testing (Web Application Pentest) Beschreibung Prüfung der Datenbankverbindungen im Rahmen einer Security Untersuchung. Analyse der verwendeten technischen DB User seitens der Anwendung auf die DB, deren Verbindungsart (SSL) und das Berechtigungskonzept seitens DB. Das Modul geht vom Prinzip "Least Privileges" aus. Damit ist gemeint, dass eine Anwendung auf die für die Anwendung notwendigen Privilegien wie lesen, schreiben, oder verändern reduziert wird. Es soll verhindert werden, dass aus einer Anwendung heraus ein DB Vollzugriff (DBA, SA) oder sogar ein Ausbruch auf das Betriebssystem möglich ist. Dieses Testing Modul fokussiert sich auf die Anwendungsebene bei IT Security Untersuchungen. Dort wo das Network Testing oder Local Testing Modul sich gegenüber der Anwendung abgrenzt, beginnt das Application Security Testing. Typischerweise werden die Tests mit Test Accounts durchgeführt und möglicherweise die Konfiguration des Application Server oder FAT Client in der Beurteilung berücksichtigt. Das Web App Security Testing Modul fokussiert sich auf die meistverbreitete Art aller Applications auf die Web Anwendung. Hierbei werden Test Accounts für den Login vorausgesetzt, und die Sicherheit der Web Anwendung auf OWASP TOP 10 Sicherheits- und Compass Web Checklists untersucht. Prüfungen gegenüber SQL Injection, Cross Site Scripting, HTML Injection, Session Fixation, AJAX Hacking etc. sind in diesem Modul enthalten Implementation Testing Haben Sie eine neue Funktion in Ihrer Anwendung? Setzten Sie einen neuen Algorithmus oder eine Technologie ein? Wurde das bestehende Konzept mit Erneuerungen erweitert? Falls Sie diese Fragen mit "JA" beantworten können, dann benötigen Sie das Testing Module "Implementation Test" Folgende Arbeiten werden bei Implementation Tests durchgeführt Workshop mit dem Team bezüglich der Neuerung Konzept Review der neuen Funktionalität auf Papier Source Code Analyse der neuen Funktionalität Implementation Check der neuen Funktionalität in der Test-, Staging- oder Produktivumgebung Reverse Engineering von eingesetzten Komponenten (FAT Clients) Aufzeigen des Deltas zur 'alten' Variante Typischerweise kommt das Implementation Testing auch zum Einsatz, wenn eine neue Bibliothek oder zum Beispiel ein neuer Authentisierungsmechanismus zum Einsatz kommt. Seite: 4

5 1.2.3 Local Testing Wie gut ist das System gehärtet? Sind nur die wirklich notwendigen Services aktiv? Werden diese Prozesse mit einem wenig privilegierten User gestartet? Wie gut ist das System auf dem neuesten Patch Level? Sind die Filesystem Berechtigungen derart gesetzt, dass ein bestmöglicher Schutz vor lokalen Angreifern besteht? Sind die Small Services des Betriebssystems wie SSH, DHCP, Sendmail, etc. sicher konfiguriert, falls diese benötigt werden? Falls Sie diese Fragen mit "JA" beantworten können, benötigen Sie das Testing Module "Local Testing". Hierbei gibt es verschiedene Vorgehensmethoden Unix: Compass liefert ein Shell Script, das nach dem Review des Kunden als "root" auf dem zu untersuchenden Host gestartet wird. Die Output Ergebnisse werden an Compass zur Beurteilung retourniert. Unix und Windows: Compass arbeitet interaktiv zusammen mit dem Kunden als "root" oder Admin auf dem zu prüfenden System und erstellt Logs und Screenshots. Diese Ergebnisdaten werden im Anschluss bei Compass beurteilt. Üblicherweise wird im Anschluss an die Auswertung noch ein Meeting oder ein Telefonat mit einer fachkundigen Person abgehalten, damit allfällige Fragen zur Konfiguration geklärt werden können Remote Testing Wie gut ist das System im Netzwerk sichtbar? Kann ein Angreifer Produkt und Version wie auch die bereitgestellten Services identifizieren und potenzielle Schwachstellen feststellen? Soll die Frage beantwortet werden, ob es bekannte Sicherheitslücken gibt? Falls Sie diese Frage mit "JA" beantworten, dann benötigen Sie das Remote Testing Module. Das Modul wird auch durch die OSSTMM Methodik definiert, die beschreibt, welche Arbeiten bei einem Remote Testing durchgeführt werden sollten. Dies umfasst: Passive und aktive Informationsbeschaffung Portscanning des zu testenden Systems vom lokalen oder einem fremden Netz aus. Vulnerability Scanning des Zielsystems False-Positive Bewertung der Ergebnisse Manuelle Tests je nach Art und Typ der identifizierten Dienste Auf Wunsch können auch Schwachstellen ausgenutzt werden Die Scanning Szenarien können wahlweise auch aus dem Modul "Network Testing" hergeleitet werden. Hierbei kann es auch vorkommen, dass das System über eine Firewall oder IPS hinweg analysiert wird, falls diese Fragestellung von Interesse ist. Die Angriffe sollten in der Regel in einer möglichst produktionsnahen Umgebung durchgeführt werden. Falls produktive System betroffen sind, kann Compass Security die Tests so gestalten, dass die Wahrscheinlichkeit eines Systemabsturzes verschwindend klein ist. Seite: 5

6 1.2.5 Network Testing Wie gut ist das System in die IT Architektur eingebettet? Ist die Zonenbildung mittels Firewall oder Router korrekt und adäquat? Welche Gefahr geht vom Office-, Management- oder Support LAN aus? Falls Sie an der Beantwortung dieser Fragen interessiert sind, benötigen Sie das Network Testing Module. Typischerweise wird dieses Modul mit der sogenannten Szenario Technik untersucht. Dabei werden verschiedene Angreifer in unterschiedlichen Netzen angenommen, welche einen Angriff auf das Zielsystem vornehmen. Diese Szenarien werden mit dem Kunden besprochen, priorisiert und in einem Testplan abgesprochen. Das Network Testing Module basiert auf folgenden Arbeiten Beurteilung IT Architektur und Netzlayout / Zonenbildung Erstellung der Szenarien und Abstimmung mit dem Kunden Durchführung der Szenarien mit dem Firewall Admin an der FW Console Durchführung der Szenarien mittels Remote Testing Module. Zur Vervollständigung dieser Art von Tests werden in der Regel auch Konfigurationsanalysen der Netzwerkkomponenten durchgeführt. Das heisst, es werden Firewall, LoadBalancer, IDS, IPS, Router oder Switch-Konfigurationen bezüglich Sicherheit und Zugriffsschutz beurteilt DB Testing Mit welchem User verbindet eine Anwendung auf eine Datenbank? Hat dieser User lediglich die notwendigen Rechte um Tabellen zu schreiben, zu erweitern und zu löschen? Gibt es eine Trennung zum administrativen User der das Schema kontrolliert? Ist sichergestellt, dass dieser User keine DBA/SA/Root Rechte erlangen kann? Ist die Verbindung verschlüsselt und geschützt gegen Man in the Middle Attacken wie auch Lauschattacken? Wenn Sie diese Fragen mit "JA" beantworten, dann benötigen Sie das DB Testing Module. Beim DB Testing Module wird untersucht, wie die Verbindung und die Rechte des DB Users auf der DB sind, um die Anforderungen an "least privileges" zu beurteilen. Typischerweise gehören dazu folgende Arbeiten Beurteilung TCPDUMP Aufzeichnung der DB Verbindung (falls über das Netzwerk) Analyse der Datenbank Rechte, zusammen mit dem DB Admin, um zu prüfen, dass der User least Privileges in der DB und keine Möglichkeit für Ausbruch auf DBA oder Root Rechte hat. Untersuchung für die Verwaltung von DB Credentials bei der Anwendung Die Untersuchung der Datenbank geschieht in der Regel unter dem Beisein des DB Administrators. Gemeinsam werden dann die zu erarbeitenden Resultate und Commands besprochen. Seite: 6

7 1.2.7 Application Security Testing Haben Sie eine neue Anwendung entwickelt, eingekauft oder betrieben? Ist Ihnen der Security Level der Anwendung unbekannt? Möglicherweise ist die Anwendung eine Blackbox? Falls Sie diese Fragen mit "JA" beantworten können, benötigen Sie das Application Security Testing Module. Dieses Modul ist für jede Art von Anwendung gedacht, mit Ausnahme von Web Anwendungen. Normalerweise werden auch Login Test Daten zur Verfügung gestellt, damit man die Sicherheit als authentisierter Benutzer überprüfen kann. Dies ist insbesondere bei Autorisierungstests notwendig. Dieses Modul umfasst folgende typische Arbeiten Analyse der Anwendungsverbindungen Analyse der verwendeten Protokolle Prüfung der Verschlüsselung bzw. CipherSuites und des Credential Management Beurteilung der Anwendungsarchitektur (z.b. FAT Client oder ähnlich) Configuration Review Server Teil Configuration Review Client Teil Reverse Engineering Client Software (falls nötig) Web Application Security Testing Haben Sie eine neue Web Anwendung im Einsatz? Wie gut ist dieses Web GUI gegenüber Web Attacken wie SQL Injection, Cross Site Scripting, Session Fixation und ähnlichem geschützt? Falls Sie diese Fragen mit "JA" beantworten können, benötigen Sie das Web Application Security Testing Module. Das Modul richtet sich nach den OWASP/WASC Standards und überprüft die Sicherheit der Application mit automatisierten Web Security Tools wie auch durch manuelle Tests. Normalweise werden auch Login Test Daten zur Verfügung gestellt, damit man die Sicherheit als authentisierter Benutzer überprüfen kann. Dies ist insbesondere bei Autorisierungstests notwendig. Ein Web App Test enthält folgende Arbeiten Analyse Web Anwendung mit Web Vulnerability Scanning Methoden Analyse Web Anwendung mit Manual Hacking Bereitstellung rekursives Directory Listing des Servers (falls nötig) durch den Kunden Remote Hacking auf das Web GUI, ohne Configuration Review der Application Server Reverse Engineering Web 2.0 Technologien (Applet, Flash, Silverlight, Java Native Client, GWT, RAP) Die Configuration Review des Servers wird durch das Modul "Application Security Testing" abgedeckt. Seite: 7

8 1.3 Checklisten Network Pentest What is the main focus of the tests? [ ] Get to know all effective and potential vulnerabilities to be able to improve the perimeter security. [ ] Showcase for awareness purposes. Thus, penetration testers must break-in and steal internal data. Check the steps you'd expect us to perform [ ] Information Gathering. Acquisition of the IP addresses and domain-names of the customer's perimeter network based on public information [ ] Visibility Scan. Identification of the accessible systems using network scanning techniques. [ ] Vulnerability Scan. Scanning and Internet research to locate weaknesses within the identified services. [ ] Manual Hacking. Attacks on the services as an anonymous user. Exploitation of critical issues that could lead to a denial of service condition will not be conducted or only if requested by the customer. [ ] Exploitation of critical issues. This could lead to DoS conditions or system break-down. [ ] Web Application Hacking. Verify if identified applications are resistant to common application security threats such as SQL injection and cross-site scripting, etc. [ ] Indirect Attacks. A CD-Rom/USB stick containing a Trojan Horse (self-programmed) shall be sent to few persons. It will be tested whether the prevention methods such as proxy, content-filter, Anti-Virus products or personal firewalls are effective. Check which of the following items you are going to provide to the penetration testers. The items left unchecked must be identified by the testing company itself. [ ] None [ ] Company names [ ] IP address ranges (subnets) [ ] IP addresses (hosts) [ ] A list of target persons for malware attacks Please give a rough estimate of the amount and scale of the networks to be penetrated Approx. number of A-Class Subnets to be investigated in Approx. number of B-Class Subnets to be investigated in Approx. number of C-Class Subnets to be investigated in Approx. number of expected hosts (+/- 20%) Please describe the artifacts you are going to expect: [ ] Non-technical management summary Language (EN/DE): [ ] Vulnerability table to be able to track issues. The weakness table must list all discovered issues and give hints for elimination (technical language) Language (EN/DE): Seite: 8

9 [ ] Technical details on the performed tests. The appendix must contain all test cases and test protocols to allow the customer personnel to look up technical details and to reproduce and retest vulnerabilities. Language (EN/DE): [ ] Non-technical management presentation. Presentation and discussion of the results in a non-technical language. Language (EN/DE):, Location: [ ] Concluding technical discussion. Discussion of the penetration test results and answering and resolving of open questions regarding the report. Language (EN/DE):, Location: Web Application Pentest Business Case of the Application Short description of the business case - Short description of the main use cases Coverage [ ] Identify low-hanging fruits only [ ] Cover OWASP Top Ten [ ] In-depth analysis Check the items that must be tested (please complete) [ ] Specific functionality only [ ] Traffic Encryption [ ] Session Handling [ ] Authentication [ ] Authorization and Access Control [ ] Input Validation and Output Encoding [ ] Transaction Safety Exposure [ ] Application is reachable over Internet [ ] Application is reachable over Internet for partner networks only [ ] Application is reachable within the internal network only [ ] Application displays content from third-party content providers [ ] Application makes use of third-party hosted scripts (eg. Google Analytics) [ ] Application provides back-office functionality Architecture Components [ ] Network Firewall [ ] EntryServer, ReverseProxy, ApplicationLevelFirewall, WAF, SOAP Firewall [ ] Webserver, Presentation Server [ ] Business Logic Server [ ] Database SQL, XML-based, file-based [ ] Authentication Server (LDAP, AD, RADIUS, RSA ACE, RACF) [ ] Access to ERP Systems Seite: 9

10 Client Technology [ ] Plain HTML (no client logic) / Browser based [ ] Client Side Applet [ ] Client Side Flash [ ] Client Side ActiveX [ ] Java Fat Client (must be downloaded, installed) [ ] Windows Binary Client Application [ ] Rich Client: HTML with JSON/AJAX/Web2.0 [ ] WebService/SOAP Client Application Complexity [ ] Content is managed in a CMS [ ] 1-5 unique Input Forms/Dynamic Pages [ ] 6-20 unique Input Forms/Dynamic Pages [ ] unique Input Forms/Dynamic Pages [ ] more than 100 unique Input Forms/Dynamic Pages Authentication [ ] Only anonymous users (public access) [ ] Username/Password authentication with self-registration [ ] Username/Password authentication (managed) [ ] User/Pass/OTP, mtan, challenge-response, time-based, SecurID [ ] Client certificates (Soft-Cert) [ ] SmartCard Role-Concept / Authorization [ ] Only one role [ ] Users/Admins [ ] Different roles (2-4 roles) [ ] Fine grained role concept (many different roles) [ ] 4-eyes principle implemented [ ] 6-eyes principle implemented Frameworks, APIs, Technologies name all APIs, Plug-ins, Libraries and Technologies you use e.g. Struts, Seam, JSF, Spring, Symfony, Apache Xerces, jquery, AJAX, JSON, Google Web Toolkit... Language Java, C++, C#, Visual Basic, Cobol, Ansi C, Pascal, PHP, Ruby, Perl, Python, JavaScript, ActionScript Seite: 10

11 1.3.3 Source Code Review Business Case of the Application Short description of the business case - Short description of the main use cases Functions and Services Is there a login page? - Are there different roles (authorization levels)? - If there are different roles: how many? - Are there any third-party service that the application connects to? - Is there any backoffice functionality? Check the items that must be tested (please complete) [ ] Authentication [ ] Authorization [ ] Input Validation [ ] Output Encoding [ ] Database Access [ ] Race Conditions [ ] Transaction Safety [ ] Encryption Routines [ ] Integrity Check Features [ ] Secure Programming Practice Language Java, C++, C#, Visual Basic, Cobol, Ansi C, Pascal, PHP, Ruby, Perl, Python, JavaScript, ActionScript Frameworks, APIs, Technologies name all APIs, Plug-ins, Libraries and Technologies you use e.g. Struts, Seam, JSF, Spring, Symfony, Apache Xerces, jquery, AJAX, JSON, Google Web Toolkit... Total Lines of Code (TLoC) /- 10% Estimated Lines of Code subject to review e.g. 10% of TLoC Seite: 11