Whitepaper (SySS GmbH)files.messe.de/abstracts/63759_whitepaper_syss_deutsch.pdf · 2015. 10....

Whitepaper

Durchführung undGestaltungsmöglichkeitenvon Penetrationstests

Sebastian Schreiber

Über den Geschäftsführer

1993 – 1999 Studium der Informatik, Physik, Mathematik und BWL ander Eberhard Karls Universität Tübingen

1996 – 1998 Mitarbeiter bei Hewlett-Packard1996 MicroGold (USA)1998 – 2015 Geschäftsführer der SySS GmbH

Zahlreiche Veröffentlichungen, Vorträge im In- und Ausland sowie Mitheraus-

geber des Fachmagazins „IT-Sicherheit und Datenschutz“

Stand: 11. März 2015

AutorenSebastian Schreiber sebastian.schreiber@syss.deMicha Borrmann micha.borrmann@syss.dePhilipp Buchegger philipp.buchegger@syss.deMatthias Deeg matthias.deeg@syss.deSven Freund sven.freund@syss.deKatrin Heinrich katrin.heinrich@syss.deSven Wiebusch sven.wiebusch@syss.de

QualitätssicherungKirsten Heitmann (Technische Prüfung) kirsten.heitmann@syss.deMarcus Bauer (Lektorat) marcus.bauer@syss.deKim Unger (Lektorat) kim.unger@syss.de

Inhaltsverzeichnis | Whitepaper 3

Inhaltsverzeichnis

1 Penetrationstests 51.1 Gestaltungsmöglichkeiten . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.1.1 Testgegenstand und Testabdeckung . . . . . . . . . . . . . . . . . . . . . . . . 51.1.2 Testtiefe und Testfrequenz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61.1.3 Testmodelle (Black-, White- and Greybox) . . . . . . . . . . . . . . . . . . . . 71.1.4 Testperspektive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81.1.5 Technische Risiken bei Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . 81.1.6 Angekündigte oder unangekündigte Prüfungen - Verdeckte oder offensicht-

liche Tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.1.7 Besondere Vorgehensweise . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141.1.8 Werkzeuge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

1.2 Standard-Testphasen . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.1 KICKOFF: Kickoff . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161.2.2 MODUL: Durchführung der Sicherheitsprüfung (gewählte Module) . . . . 171.2.3 DOCU: Dokumentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171.2.4 PRES: Präsentations-Workshop . . . . . . . . . . . . . . . . . . . . . . . . . . 181.2.5 RETEST: Nachtest . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

2 Mögliche MODULE 202.1 PERIM: Perimetererkennung . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202.2 INTERNET: Analyse aus dem Internet . . . . . . . . . . . . . . . . . . . . . . . . . 212.3 WEBAPP: Prüfung von Webapplikationen . . . . . . . . . . . . . . . . . . . . . . . . 23

OWASP Top 10 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252.4 WEBSERVICE: Prüfung von Webservices . . . . . . . . . . . . . . . . . . . . . . . . 312.5 LANWAN: Sicherheitstest im internen Netz . . . . . . . . . . . . . . . . . . . . . . . 33

2.5.1 Putzpersonal-Szenario (Modul LANWAN/CLEAN) . . . . . . . . . . . . . . 362.5.2 Praktikanten-Szenario (Modul LANWAN/TRAINEE) . . . . . . . . . . . . . 372.5.3 Client-Analyse (Modul LANWAN/CLIENT) . . . . . . . . . . . . . . . . . . . 372.5.4 Targeted Attacks (Modul LANWAN/TARGET) . . . . . . . . . . . . . . . . . 382.5.5 VoIP und VLAN (Modul LANWAN/VOIP und LANWAN/VLAN) . . . . . 39

2.6 WLAN: Test des Drahtlosnetzwerks . . . . . . . . . . . . . . . . . . . . . . . . . . . . 402.7 MOBILE: Sicherheitstest von mobilen Endgeräten und Mobile Device Management 42

2.7.1 Sicherheitstest von Apple iOS-Geräten . . . . . . . . . . . . . . . . . . . . . . 422.7.2 Sicherheitstest von Android-Geräten . . . . . . . . . . . . . . . . . . . . . . . 442.7.3 Prüfung von Mobile Device Management Lösungen . . . . . . . . . . . . . . 46

2.8 INDIVIDUAL: Individuelles Anliegen . . . . . . . . . . . . . . . . . . . . . . . . . 482.8.1 Pivot - Kompromittierte Demilitarized Zone (DMZ) . . . . . . . . . . . . . . 482.8.2 Sicherheit von Anwendungen und Desktop-Systemen über Citrix Access

Gateway . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 502.8.3 Produkt-/Labortests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 512.8.4 Prüfung organisatorischer Vorgaben . . . . . . . . . . . . . . . . . . . . . . . . 52

4 Whitepaper | Inhaltsverzeichnis

2.8.5 Simulierter Phishing-Angriff . . . . . . . . . . . . . . . . . . . . . . . . . . . . 532.9 Grundlagen des Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55

2.9.1 Grenzen von Sicherheitstests . . . . . . . . . . . . . . . . . . . . . . . . . . . . 552.9.2 Abgrenzung von Sicherheitstests zu anderen Prüfungen . . . . . . . . . . . . 55

3 Digitale Forensik & Incident Response 563.1 Digitale Forensik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 563.2 Incident Response . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

4 Über die SySS GmbH 584.1 Firmengeschichte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 584.2 Grundlegende Ethik für Penetrationstester . . . . . . . . . . . . . . . . . . . . . . . . 584.3 Veröffentlichungen der SySS GmbH (Auswahl) . . . . . . . . . . . . . . . . . . . . . . 60

Penetrationstests | Whitepaper 5

1 Penetrationstests

Seit fünfzehn Jahren führt die SySS GmbH Sicherheitstests durch. Die dadurch gewonnenenErkenntnisse bilden das Fundament dieses Whitepapers. Dabei hat die SySS GmbH ihre Erfahrungsowohl bei großen multinationalen als auch bei traditionellen mittelständischen Unternehmengesammelt. Ferner basiert dieser Leitfaden auf den praktischen Erfahrungen unserer IT-SecurityConsultants und auf der intensiven Kommunikation mit unseren Kunden.

Sicherheits- oder Penetrationstests versteht die SySS GmbH als aktive Qualitätskontrolle derIT-Sicherheit. Innerhalb dieses Bereichs liegt die Kernkompetenz im Test von klassischen Netzen,Webapplikationen und WLANs.

Das Whitepaper unterstützt Sie dabei, die richtigen Testgegenstände und das dazu aus demAngebot der SySS GmbH passende Testverfahren auszuwählen. Zudem wird dargestellt, wel-che Voraussetzungen nötig sind, damit ein Test effizient und im positiven Sinne erfolgreichdurchgeführt werden kann.

Insbesondere wird gezeigt, welche Entscheidungen und Maßnahmen erforderlich sind, damitder Test auch intern in Ihrem Unternehmen als eine besonders positive Dienstleistung wahr-genommen wird.

1.1 Gestaltungsmöglichkeiten

Aufgrund der Unterschiedlichkeit der diversen Testgegenstände können Sicherheitstests nichtnach einem festen, standardisierten Verfahren ablaufen, sondern müssen flexibel gestaltet werden.Diese Gestaltung ist von mehreren Faktoren abhängig:

• Perspektive, aus der der Test durchgeführt wird (siehe Abschnitt 1.1.4 auf Seite 8),• Umgang mit DoS (Denial of Service)-Potentialen (siehe Abschnitt 1.1.5 auf Seite 8),• Interne Koordination des Testablaufs (siehe Abschnitt 1.1.6 auf Seite 12),• Zu testende Systeme bzw. Anwendungen (siehe Abschnitt 1.1.1 auf dieser Seite),• Mögliche Schwerpunkte (siehe Abschnitt 1.1.2 auf der nächsten Seite),• Regelmäßigkeit der Tests (siehe Abschnitt 1.1.2 auf der nächsten Seite),• Besonderheiten beim Testverfahren (siehe Abschnitt 1.1.6 auf Seite 12),• Gewählte Testmodule (siehe Abschnitt 1.2.2 auf Seite 17).• Dem zur Verfügung stehenden Budget.

1.1.1 Testgegenstand und Testabdeckung

Sowohl bei externen (Modul INTERNET) als auch bei internen Tests (Modul LANWAN) sinddie Testgegenstände Systeme, die durch ihre IP-Adressen identifiziert werden. Aus der Gesamtheitder IP-Adressen wählt der Kunde entweder eine repräsentative Stichprobe aus oder es werden

6 Whitepaper | Penetrationstests

alle getestet. Bei dem Test von Webapplikationen (Modul WEBAPP) ist der Testgegenstand einewebbasierte Anwendung bzw. deren Funktionalität.

Bei der Untersuchung von WLANs (Wireless LANs) ist der Testgegenstand wiederum dasWLAN an einem Standort des Kunden sowie daraus ausgewählte Clients. Die Testabdeckungbeschreibt hier zum Beispiel die Größe des zu untersuchenden Campus oder die Anzahl der zuprüfenden Gebäude. Der Testgegenstand und die Testbreite werden bei der Angebotserstellungberücksichtigt. Hier wird auch der Zeitbedarf kalkuliert. Aufgrund der Vielfalt an Systemen undAnwendungen, die bei allen Testgegenständen zum Einsatz kommen können, sind pauschaleAussagen schwierig. Wir empfehlen Ihnen daher, den Testgegenstand vorab direkt mit uns zubesprechen. Im Allgemeinen wird – insbesondere bei großen Unternehmen – im Rahmen einesTests nicht das gesamte interne oder externe Netz geprüft, sondern eine sinnvolle Auswahlgetroffen. Als Sonderform ist es möglich, dass die SySS GmbH aus einem oder mehreren Netzenselbständig Stichproben auswählt. Stellt entweder der Kunde oder die SySS GmbH währendeines Tests fest, dass Änderungen sinnvoll sein könnten, so sind Anpassungen, die die Testdauerinsgesamt nicht verändern, unbürokratisch möglich. Sie werden in direkter Absprache zwischendem durchführenden Consultant und dem Ansprechpartner des Kunden vorgenommen.

1.1.2 Testtiefe und Testfrequenz

Die Testtiefe ergibt sich automatisch aus dem gewählten Testgegenstand und der zur Verfügungstehenden Zeit. Ist ein Testziel beispielsweise die Überblicksgewinnung über eine große Anzahlvon Systemen in vergleichsweise kurzer Zeit, so ist die Testtiefe des einzelnen Systems niedrigund die Suche nach sehr hohen Risikopotentialen hat Priorität. Steht dagegen viel Zeit für wenigeSysteme zur Verfügung, so können zum Beispiel selbst Fehlkonfigurationen erfasst werden, vondenen kein direktes Sicherheitsrisiko ausgeht, die aber die Funktionstüchtigkeit nicht optimalausschöpfen.

Die Schwerpunktsetzung bei der Untersuchung des im Angebot definierten Testgegenstandeswird im Kickoff besprochen. Das generelle Ziel ist, innerhalb des Testzeitfensters festzustellen, wiedas aktuelle Sicherheitsniveau des Testgegenstands aussieht und von welchen Sicherheitslückendas größte Risiko ausgeht. In der Regel wird der durchführende Consultant mehr Aufwandin den Nachweis von Sicherheitslücken investieren, die ein Eindringen Dritter ermöglichen,als in die detaillierte Untersuchung von Fehlern, die lediglich ein minimales Risiko darstellen.Endgültiges Ziel ist es, ein möglichst umfassendes Gesamtbild über den Sicherheitszustanddes Testgegenstandes zu erstellen, Risiken klar zu benennen und Vorschläge zur Behebungzu unterbreiten. Dies alles geschieht in der Form eines Berichts (Modul DOCU). Wenn dieNotwendigkeit erkannt wird, während des Tests die Schwerpunktsetzung oder Testtiefe zu ändern,so ist auch dies im direkten Gespräch zwischen Consultant und Ansprechpartner möglich. DaSicherheitstests keine linearen Abläufe sind, bietet die SySS GmbH hier die nötige Flexibilität.

Sicherheitstests können ihre maximale Wirkung auf den Sicherheitsprozess nicht entfalten, wennsie nur einmalig stattfinden – denn die Maßnahmen, die nach einem Test zur Behebung festge-stellter Sicherheitslücken durchgeführt werden, sollten für die Mitarbeiter oder Dienstleister zurRoutine werden. Auch Softwareupdates oder das Hinzufügen oder Entfernen von Modulen o.ä.können zu neuen Sicherheitslücken führen.

Für nachhaltige Ergebnisse sollte der Sicherheitstest vollständig in den Sicherheitsprozess integriertund turnusmäßig durchgeführt werden. Unternehmen, die einen hohen Wert auf die IT-Sicherheitlegen, konzipieren Testpläne, die zwei bis drei Jahre in die Zukunft reichen:

Q12015

Q22015

Q32015

Q42015

Q12016

Q22016

Q32016

Sicherheitstest der Systeme im Internet(Modul INTERNET)Untersuchung der Webapplikationen(Modul WEBAPP)Interner Penetrationstest(Modul LANWAN)WLAN-Test(Modul WLAN)

Dabei muss der permanente Wandel von IT-Netzen und Anwendungen berücksichtigt werden.Die Planung sollte etwa halbjährlich überdacht und aktualisiert werden. Der Testgegenstandsollte so gewählt werden, dass sich der Nutzen maximiert und keine Routine im Sinne einerGleichgültigkeit gegenüber den Testergebnissen eintritt. Der Testplan sollte langfristig angelegtsein, denn nur so lassen sich auftretende Schwachpunkte identifizieren und ein professionellesQualitätsmanagement nachweisen.

1.1.3 Testmodelle (Black-, White- and Greybox)

Bei einem Sicherheitstest wird sowohl eine bestimmte Perspektive eingenommen (siehe Ab-schnitt 1.1.4 auf der nächsten Seite) als auch von einem bestimmten Wissensstand des potentiellenAngreifers ausgegangen. Die SySS GmbH orientiert sich bei Bedarf an dem Blackbox-, Whitebox-und Greybox-Modell.

Blackbox-Modell

Bei diesem Modell werden durch den Kunden nur minimale Informationen zu dem Testgegenstandübermittelt.

Ein Blackbox-Test darf dabei aber keinesfalls als Test missverstanden werden, bei dem keinerleiInformationsfluss zwischen Tester und Kunde stattfindet und Ziele völlig selbständig gewähltund geprüft werden. Rechtliche Gegebenheiten erlauben das Testen von fremden Systemenohne ausdrückliche Erlaubnis des tatsächlichen Betreibers nicht. Vor einer Prüfung muss zudemstets verifiziert werden, ob ein Test des Systems oder des Netzes unter organisatorischen undtechnischen Gesichtspunkten sinnvoll ist. Falls sich die Auswahl aufwendig gestaltet, kann einePerimetererkennung durchgeführt werden (Modul PERIM). Dabei identifiziert die SySS GmbHTestziele weitgehend selbständig. Die Ergebnisse und die Stichprobenauswahl werden mit demKunden besprochen, der die Testfreigabe erteilt und die nötigen Genehmigungen beschafft.

Whitebox-Modell

Bei Tests im Rahmen des Whitebox-Modells werden umfangreiche Informationen über denTestgegenstand übermittelt. Die sonst übliche Menge an Informationen für die Durchführungeines Sicherheitstests ist im Rahmen des Moduls INTERNET nicht erforderlich.

Greybox-Modell

Sicherheitstests der SySS GmbH folgen in der Regel diesem Modell. Dabei werden von demKunden exakt die Informationen zur Verfügung gestellt, die zur effizienten Durchführung einesSicherheitstests nötig sind. Falls höherer Informationsbedarf besteht, werden Rückfragen an einenAnsprechpartner des Kunden gestellt. Die für das Testmodul notwendigen Informationen werdenunter „Mitwirkung des Kunden“ innerhalb des entsprechenden Moduls besprochen. Aufgrundihrer langjährigen Erfahrung erachtet die SySS GmbH dieses Modell als die effizienteste Methode.

1.1.4 Testperspektive

Die unterschiedlichen Positionen, die ein potentieller Angreifer einnehmen kann, werden durchunterschiedliche Testabläufe abgedeckt. Es kann geprüft werden, welche Infrastruktur des Kundenüberhaupt aus dem Internet erreichbar ist. So wird das Risiko ermittelt, Ziel von Angriffenüber das Internet zu werden (Modul PERIM). Dies kann auch als Inventarisierungsmaßnahmeverstanden werden.

Es kann jedoch auch geprüft werden, welches Risiko konkret von im Internet erreichbarenSystemen durch nicht-autorisierte Nutzer ausgeht, werden diese Systeme einem externen Testunterzogen (Modul INTERNET).

Davon zu unterscheiden ist der Test von Webapplikationen. Er findet primär aus der Perspektivevon regulären Nutzern (im Gegensatz zu nicht angemeldeten Besuchern) einer webbasiertenAnwendung statt, auch wenn er vom Internet aus durchgeführt wird (Modul WEBAPP). DerTest kann zusätzlich auch die Perspektive des unangemeldeten Besuchers einnehmen.

Der Sicherheitstest im internen Netz (Modul LANWAN) prüft das (Firmen-)Netz aus derPerspektive des Innentäters. Zwangsläufig findet er daher am Objekt statt. Bei einem internenTest sind in der Regel sehr viele Systeme, die ihrerseits auch viele Dienste anbieten, erreichbar.Daher muss die Art der Durchführung hier angepasst werden. Dies umfasst unter anderem eineKonzentration auf die Feststellung von schwerwiegenden Sicherheitslücken, die leicht ausgenutztwerden können.

Bei den Sicherheitstests von WLANs (Modul WLAN) wird zunächst einmal die Perspektiveeines Angreifers in der Reichweite einer WLAN-Antenne eingenommen. Hier wird geprüft, obbeispielsweise die unberechtigte Nutzung eines Netzes möglich ist oder bestehende Verbindungenvon Teilnehmern kompromittiert werden können. Ebenso wie der interne muss der WLAN-Testvor Ort stattfinden.

1.1.5 Technische Risiken bei Sicherheitstests

Bei Sicherheitstests können mehrere Risiken auftreten, die in diesem Abschnitt erläutert werdensollen.

Denial of Service

DoS (Denial of Service)-Potentialen kommt eine besondere Bedeutung zu. Zum einen können diesedurch Fehler in Diensten selbst auftreten, zum anderen durch Fehlkonfigurationen. Generell ist es

nicht das Ziel eines Sicherheitstests, Systeme oder Anwendungen außer Kraft zu setzen, sondernzu überprüfen, ob dies möglich ist und welche Gefahr hiervon ausgeht.

Folgendes Vorgehen hat sich bei der Erkennung von DoS-Potentialen besonders bewährt: Wirdein solches gefunden, kontaktieren wir zuerst den Ansprechpartner des Kunden. Im direktenGespräch wird entschieden, ob die SySS GmbH den tatsächlichen Nachweis führen soll (alsodie Störung auslösen) oder nicht. Das Ausnutzen eines DoS-Potentials kann sinnvoll sein, wennder Kunde ein klares Signal wünscht, dass an einem bestimmten System Änderungen (Wartung,Abschottung oder gar Ersatz) nötig sind.

Tests, deren Ziel es ist, durch den Verbrauch von Bandbreite Netze lahmzulegen, führt die SySSGmbH nicht durch. Das Risiko durch derartige Angriffe besteht immer und kann durch dieBetrachtung der zur Verfügung stehenden Bandbreite jederzeit ermittelt werden.

Da es sich bei einem Sicherheitstest um eine aktive Kontrolle handelt, kann nie völlig ausgeschlos-sen werden, dass die zu testenden Systeme beeinträchtigt werden. Beeinträchtigungen könnensowohl bei Funktionen einzelner Dienste, dem getesteten Dienst selbst als auch dem gesamtengetesteten System auftreten. Insbesondere beim Test von Webapplikationen wird normalerweisenicht von DoS-Potentialen ausgegangen. Da aber während eines Tests Abfragen an die Datenbankgestellt werden können, die reguläre Anwender nicht erzeugen, bestehen diese Risiken auch hier.Oft ist es schwer, derartige Probleme vorherzusehen. Gibt es jedoch klare Indikatoren dafür, kannwie bereits dargestellt vorgegangen werden. Einen Sicherheitstest durchzuführen, der keinerleiRisiken birgt, ist nicht möglich.

Zwei Umstände sind nach der Erfahrung der SySS GmbH für Denial of Service bei Sicherheitstestsverantwortlich: Zum einen können Systeme oder Anwendungen DoS auslösen, die auch mit dernur moderaten Last eines Tests nicht umgehen können und zum anderen bergen sehr alte undungepflegte Dienste ein nicht unerhebliches DoS-Potential. Generell sollte bei der Vorbesprechung(Kickoff) angesprochen werden, ob und wie alte oder sehr alte Systeme getestet werden (z. B. mitstark veraltetem Patch-Stand) oder ob Lastprobleme ohnehin auftreten. Um letzteres Problem zuumgehen, kann auch vereinbart werden, bestimmte Prüfungen außerhalb von Spitzenlastzeitendurchzuführen. Penetrationstests unterscheiden sich nur punktuell von Funktions-, Last- undVerbindungstests. In gleicher Weise wie bei derartigen Tests muss bei einer Sicherheitsüberprüfungmit einem bestimmten Datenvolumen gerechnet werden, welches die beteiligten Systeme wie imnormalen Betrieb abarbeiten müssen.

Der Hauptunterschied zu anderen Testverfahren ist, dass bei einem Sicherheitstest verschiedeneDienste mit Anfragen konfrontiert werden, die im Alltag nicht auftreten. Dies ist exakt das grund-legende Vorgehen zum Erkennen von Sicherheitsdefiziten aller Art, von dem nicht abgewichenwerden kann, es sei denn, man möchte auf technische Maßnahmen vollständig verzichten. Umalso möglichst viele Risikopotentiale zu vermeiden, geht die SySS GmbH wie folgt vor:

• Durchführung des Tests durch ausgebildete und erfahrene Spezialisten.• Durchführung von Penetrationstests nur nach schriftlichem Auftrag und eindeutiger Test-

freigabe für die zu prüfenden Systeme.• Prüfung der vom Kunden gelieferten Daten auf Korrektheit (z. B. IP-Ranges), bei Unklarhei-

ten erfolgt stets Rücksprache.• Durchführung eines Kickoff-Gesprächs anhand eines erprobten Verfahrens inkl. Erstellung

eines schriftlichen Protokolls.• Fortwährende Betreuung im laufenden Projekt durch einen Ansprechpartner seitens des

Kunden.• Minimierung des Risikos durch Gestaltung des Prüf-Projektes. Langsame Scans (Reduktion

der Bandbreite) erhöhen allerdings die Testdauer massiv.

• Tests können auch außerhalb der Geschäftszeit (z. B. nachts/am Wochenende) durchgeführtwerden. Wird dieses Vorgehen gewünscht, muss in dieser Zeit ein Ansprechpartner desKunden direkt zur Verfügung stehen.

• Prüfung von Testsystemen. Entspricht das Testsystem aber nur in wenigen Punkten demproduktiven System, muss die SySS GmbH im Abschlussbericht stets darauf hinweisen, umdessen Aussagekraft nicht zu verfälschen.

• Abbruch des Tests bei erkannten Schwierigkeiten: Indirekt erzeugte Probleme sind fürExterne generell nicht erkennbar. Daher muss der Ansprechpartner des Kunden in der Lagesein, auftretende Probleme eindeutig dem Test zuordnen zu können und vor allem die SySSGmbH zu informieren.

• Wahl von nicht-invasiven Prüfmethoden. Die damit einhergehende Reduktion des Erkennt-nisgewinns muss dann in Kauf genommen werden. Spekulationen werden als solche imBericht von der SySS GmbH stets gekennzeichnet.

Die SySS GmbH möchte an dieser Stelle explizit auf die permanente Verfügbarkeit eines An-sprechpartners des Kunden während eines Tests hinweisen, denn ohne diesen kann eine Reiheder oben genannten Punkte unter keinen Umständen erfüllt werden. Insbesondere sollte derAnsprechpartner auch über die Kompetenz verfügen, mit der SySS GmbH zusammen einenanderen Testverlauf zu planen und gegebenenfalls Schwerpunkte eines Tests zu ändern. Dieorganisatorischen Prozesse sollten eine gewisse Flexibilität zulassen. Sind beispielsweise dieüblichen Ansprechpartner während eines Tests nicht verfügbar, so sind Vertreter zu benennenund mit den entsprechenden Vollmachten auszustatten. Aufgrund der Erfahrungen der SySSGmbH können die Risiken auf vier technische Ursachen zurückgeführt werden, die im Folgendendargestellt werden.

Last bei Webapplikationstests

Bei Webapplikationstests wird, ähnlich wie bei Funktionstests, Last auf der Datenbank erzeugt, diedie Webapplikation versorgt. Dies kann beispielsweise eine Suche über alle Felder sein, die demNutzer der Anwendung scheinbar nicht möglich ist. Ist das System, auf welchem die Datenbankläuft, sehr knapp kalkuliert oder schlichtweg veraltet, kann dies zu Beeinträchtigungen führen.An dieser Stelle ist eine manuelle Betreuung der Datenbank durch Mitarbeiter des Kunden nötig– denn von externer Seite aus kann nur die Frequenz der Suchanfragen verändert werden, diePriorität einer Suche gegenüber anderen nicht.

Die SySS GmbH empfiehlt an dieser Stelle, derartige Systeme nicht auf ein sehr niedrig geschätz-tes Nutzungsvolumen auszulegen, sondern hinreichende Leistungsreserven vorzusehen. Diesekönnen auch durch Optimierungen an der Datenbank und der Suchroutine in der Webapplika-tion gewonnen werden. Allerdings sind bei der Verwendung von Alt- oder Uraltsystemen derLastreduzierung durch Optimierung an der Datenbank klare Grenzen gesetzt.

E-Mails an interne Adressen

Über entsprechende Funktionen können über die Webapplikation E-Mails verschickt werden,zum Beispiel Produktanfragen. Diese dürfen sich weder für Spam-Versand noch für das Fälschenvon E-Mails missbrauchen lassen. Probleme ergeben sich an dieser Stelle ebenfalls durch amMailversand beteiligte Systeme, die eine Serie automatisch erzeugter Nachrichten nicht schnellgenug abarbeiten können. Auch an dieser Stelle ist eine manuelle Betreuung der beteiligten

Systeme nötig, da von externer Seite aus über die Komposition der beteiligten Systeme nurAnnahmen gemacht werden können.

Ausfall von Infrastrukturkomponenten

Sicherheitstests erzeugen einen gewissen Netzwerkverkehr, den die beteiligten Komponenten,Router und Switches abwickeln müssen. Von ihnen wird dabei dasselbe korrekte Funktionierenwie im regulären Betrieb erwartet. Die bei einem Sicherheitstest entstehende Last entspricht inihrer Natur auch der Last, wie sie eine intensive Nutzung zahlreicher Kommunikationsdienstehervorrufen würde. Infrastrukturkomponenten, die bei solchen Tests ausfallen statt einfachlangsamer zu werden, sind extrem kritisch zu betrachten. Auch wenn sie höher liegt als beilegitimer Nutzung, so ist die Last eines Sicherheitstests nicht einmal ansatzweise mit der einesverteilten Angriffes (DDOS) zu vergleichen. Zudem besteht das Risiko, dass die Systeme auchnatürlich auftretende Lastspitzen nicht abfangen können. Dies kann zum Beispiel die positiveAnnahme eines neuen Angebotes durch den eigenen Kundenstamm sein oder Reaktionen derÖffentlichkeit auf Nachrichten.

In der Regel lassen sich derartige Vorfälle eindeutig auf die eingesetzte Hardware bzw. dieauf ihnen laufende Software zurückführen. Wird diese ohnehin vom Hersteller nicht mehrunterstützt, so empfiehlt die SySS GmbH ein Upgrade. Reduziert werden kann das Risikodurch ein langsameres Vorgehen beim Testen, welches aber die für das Projekt nötige Zeit leichtvervielfachen kann.

Nicht ausreichende Leitungskapazität

Die SySS GmbH verwendet für Tests hauptsächlich Root-Server im Internet. Sowohl die Systeme alsauch die eingesetzten Werkzeuge selbst sind für jedermann verfügbar. Die bei einem Sicherheitstestnötige Last kann daher von Dritten mit vergleichsweise geringem finanziellen Aufwand ebenfallserzeugt werden. Dies bedeutet konkret, dass jeder Breitbandanschluss in der Lage ist, eine2-Mbit-Strecke zu überlasten oder zumindest massiv zu beeinträchtigen.

Bestimmend für das Risiko ist neben der Leitungskapazität ausschließlich der Faktor Zeit. EineReduktion der benötigten Bandbreite wird immer mit einer längeren Dauer des Tests verkauft.Alternativ sind nur Stichproben möglich. Da die Leitungskapazität von externer Seite nur indi-rekt und unpräzise festgestellt werden kann, ist die SySS GmbH daher auf präzise und nicht-widersprüchliche Informationen ihres Kunden angewiesen. Die SySS GmbH hat an dieser Stellekeine Einsicht in die Verträge oder Absprachen des Kunden mit seinen Providern und kann daherdiese Informationen nicht selbst erbringen.

Generell empfiehlt die SySS GmbH, die Leitungskapazität modernen Erfordernissen anzupassen.Werden beispielsweise mehrere Class-C-Netze von einer 2-Mbit-Strecke versorgt, so gibt es inder Regel bereits Beeinträchtigungen durch die nicht ausreichende Bandbreite. Auf der anderenSeite können Kosten reduziert werden, indem einzelne Systeme im Ganzen oder teilweise externgehostet werden. Ist dies nicht möglich, weil zum Beispiel Leitungen mit entsprechender Kapa-zität vor Ort nicht für einen angemessene Preis zu haben sind, empfiehlt die SySS GmbH, einklares Konzept für den Fall aufzustellen, dass die Leitung versehentlich – keinen bösen Willenvorausgesetzt – überlastet wird und die alltägliche Nutzung dann nicht mehr möglich ist. DerAnsprechpartner des Kunden sollte in diesem Fall der jeweilige Provider sein.

1.1.6 Angekündigte oder unangekündigte Prüfungen - Verdeckte oderoffensichtliche Tests

Das Ziel von Penetrationstests ist die Aufdeckung technischer, keinesfalls menschlicher Defizite.Unangekündigte Tests werden aber von den Betroffenen als Letzteres verstanden. Dies hat für denKunden den großen Nachteil, dass Testergebnisse in Frage gestellt werden und die Motivationder Mitarbeiter, dringende Sicherheitsmaßnahmen umzusetzen, erheblich sinkt. Das Ziel einesSicherheitstests wird daher in der Regel nicht erreicht, wenn er unangekündigt durchgeführtwird, sondern schlichtweg verfehlt.

Der nachhaltige Erfolg der SySS GmbH besteht darin, dass sowohl die Ansprechpartner derKunden als auch deren Systemverantwortliche und Administratoren der Dienstleistung „Sicher-heitstest“ Vertrauen statt Misstrauen entgegenbringen. Ein zentraler Faktor ist hierbei das Angebotan alle Beteiligten, dem Test persönlich beizuwohnen.

Tipp von Sebastian SchreiberSprechen Sie mit allen Beteiligten über geplante Tests. Damit erreichen Sie, dass der Sicherheitstestals nützliche Dienstleistung aufgefasst wird und die Ergebnisse effizient bearbeitet werden.

Social Engineering1 gehört neben allen technischen Möglichkeiten zu den wirksamsten Mitteln, uman sensible Daten zu gelangen. Social Engineering bedeutet im Kontext der IT-Sicherheit den Ver-such, persönliche Daten durch Täuschung zu erlangen und kommt einem professionellen Betrugvon Menschen gleich. Die Betrüger geben sich als befugte Techniker oder externe Dienstleister ausund schaffen es, durch ihr angepasstes Auftreten gewünschte Informationen abzufragen. In derRegel haben sie auch hinreichende Kenntnisse der Unternehmenskultur, um hektische Situationen(z. B. IT-Umstellungen in großem Maßstab, Umzüge, geschäftige und betriebsame Situationenaller Art, etc.) dreist ausnutzen zu können.

Obwohl Social Engineering eine der größten Gefahren für Unternehmen birgt und die Diskussionum Maßnahmen zur Eingrenzung dieses Gefahrenpotentials durchaus berechtigt ist, gibt es einenentscheidenden Unterschied zu allen anderen Testmöglichkeiten: Der Testgegenstand ist hierbeider Mensch und keine technische Komponente. Da ein Mensch aber nicht mit einer indifferentenMaschine gleichzusetzen ist, verfehlen derartige Tests ihr vermeintliches Ziel.

Prüfer müssen bei solchen Tests eine falsche Identität annehmen und Firmenmitarbeiter unterderen Deckmantel gezielt belügen beziehungsweise in die Irre führen. Außerhalb von scharfkontrollierten Bedingungen ist dies rechtlich kritisch und organisatorisch heikel.

Die SySS GmbH empfiehlt daher, Tests durch Social Engineering nur in Ausnahmefällen in Betrachtzu ziehen.

Bei Sicherheitstests wird – wie bereits erwähnt – nicht verdeckt agiert. Der durchführendeConsultant trifft keinerlei besondere Maßnahmen, die Testaktivitäten zu verbergen. Die Erfahrungzeigt, dass Maßnahmen, die zum Beispiel geeignet sind, den Test vor automatisierten Erkennungs-oder Abwehrsystemen (IDS/IPS) zu verbergen, die Testdauer massiv erhöhen – meistens mehr,als einem normalen Projektablauf zuträglich ist. Anhand des im Rahmen der Dokumentation(Modul DOCU) erstellten Berichts kann zusätzlich nachvollzogen werden, ob beispielsweise dieTests, die Sicherheitslücken mit hohem Risikopotential nachgewiesen haben, von automatischenSystemen erkannt wurden.

1 Zu mehr Informationen und zum besseren Verständnis, siehe: http://de.wikipedia.org/wiki/Social_Engineering.

Zehn Tipps von Sebastian Schreiber1. Verstehen Sie Penetrationstests nicht als einzelnes Projekt, sondern als Prozess. Dies ermög-

licht und erzwingt eine kontinuierliche Vorgehensweise, deren Effizienz viel größer ist alsbei einer separaten Projektsicht.

2. Penetrationstests sind sehr einfach in der Planung und Vorbereitung, wenn man sie frühzeitigterminiert. Gute Unternehmen sind zwar auch in der Lage, kurzfristig große Projekte zustemmen, doch erzeugt dies stets einen vermeidbaren Mehraufwand.

3. Wohnen Sie dem Sicherheitstest bei. Dies bringt Ihnen einerseits einen nicht alltäglichenPerspektivenwechsel und andererseits ist es ein besonderes Erlebnis, die eigenen Systemeunter Beschuss zu sehen.

4. Während manche Prüfungen notwendigerweise unangemeldet durchgeführt werden müssen(wie z. B. bei Fahrkartenkontrollen, WKD), empfehlen wir, Penetrationstests anzukündigen.Dies schafft Vertrauen im Unternehmen und stärkt die Zusammenarbeit.

5. Oft sind Kunden unschlüssig, ob sie einen Blackbox- oder Greybox-Test wählen sollen.Wir empfehlen den goldenen Mittelweg: Statten Sie den Penetrationstester gezielt mit denInformationen aus, die er für sein Projekt benötigt und die ein realistischer Hacker ohnehinselbst ermitteln könnte.

6. Die Neutralität des Prüfers ist seine wichtigste Eigenschaft. Diese ist in Gefahr, wenn derPrüfer bei der Entstehung des Prüfgegenstands involviert war oder das Ergebnis einerPrüfung ihm Nutzen oder Schaden bringt. Sicherheitslücken können niemals mit derselbenDenkweise gelöst werden, mit der sie entstanden sind (frei nach Albert Einstein).

7. Oftmals fehlt es an einem passenden Budget oder Zeitfenster zur Durchführung einesPenetrationstests. Es wäre jedoch falsch, als Konsequenz gänzlich auf den Test zu verzichten.Selbst ein kompakter Test nutzt der eigenen IT-Sicherheit.

8. Sogenannte Distributed Denial-of-Service-Angriffe offenbaren, ob ein System Sabotagean-griffen standhält oder nicht. IT-Ressourcen wie Bandbreite oder CPU-Leistung sind aberprinzipiell auch ohne Penetrationstest erschöpfbar. Nach unserer Auffassung sollten sol-che Attacken vermieden werden, weil der zu erwartende Erkenntnisgewinn in keinemattraktiven Verhältnis zu möglichen negativen Auswirkungen steht.

9. Es ist offensichtlich, dass niemals sämtliche Systeme einer exakten Prüfung unterzogenwerden können. Daher ist die Wahl einer repräsentativen Stichprobe wesentlich für eineneffizienten Test. Diese ergibt sich aus einem sinnvollen Clustering, bei dem sich die Prüfge-genstände innerhalb eines Clusters stark ähneln, die Cluster selbst jedoch verschieden sind.Wird aus jedem Cluster ein Repräsentant untersucht, so erhält man eine besondere Balancezwischen Aufwand und Output.

10. Wir erleben häufig, dass der Nachtest immer wieder verschoben wird mit dem Ziel, vorheralle Lücken zu beheben. Das verschleppt die Durchführung des Nachtests und lähmt denProzess der kontinuierlichen Verbesserung. Wir empfehlen daher, den Nachtest auch danndurchzuführen, wenn noch nicht alle Lücken geschlossen sind, zum Beispiel vier Wochennach Abschluss des Haupttests. In der Regel handelt es sich bei einem Nachtest um einvergleichsweise kleines Projekt, sodass eine Wiederholung des Nachtests nach weiterensechs Wochen verglichen mit dem Gesamtbudget nicht wesentlich ins Gewicht fällt.

1.1.7 Besondere Vorgehensweise

Spezialisierung

Die SySS GmbH ist auf die Durchführung von Sicherheitstests spezialisiert und bietet zu diesemThema passende Schulungen an. Dieser extrem hohe Spezialisierungsgrad sorgt für einen großenErfahrungsschatz bei allen Consultants, der durch die regelmäßigen Tests ständig weiter ausgebautwird. Die SySS GmbH kennt dadurch die Bedürfnisse ihrer Kunden sehr genau und kann einpräzises Testergebnis liefern. Sie bietet den kritischen, aber fairen Blickwinkel des Externen aufdas Sicherheitsniveau. Beratungsleistungen bei der Behebung von erkannten Sicherheitslückensind dabei nur in minimalem Umfang nötig – denn um die Umsetzung der nötigen Maßnahmenkümmern sich unsere Kunden sehr erfolgreich selbst.

Transparenz

Die SySS GmbH legt Wert darauf, dass Sie ohne Weiteres nachvollziehen können, wie Sicherheits-lücken erkannt und im Rahmen des Tests ausgenutzt worden sind. Ein Verständnis von Hackingals einem geheimnisvollen, fremdartigen Ablauf ist kontraproduktiv zur Stärkung der SicherheitIhres Unternehmens.

Wir erreichen die notwendige Transparenz durch die folgenden Punkte:

• Eine hochwertige Dokumentation wird im Rahmen des Moduls DOCU erstellt, deren Zieldie Nachvollziehbarkeit von Sicherheitsproblemen ist.

• Es ist hilfreich, wenn der Kunde seine von Tests betroffenen Mitarbeiter und Dienstleistereinlädt, entweder teilweise oder ganz dem Sicherheitstest beizuwohnen. Dabei ist die SySSGmbH jederzeit bereit, dem Kunden mit ihrem Wissen zu dienen.

• Ergebnispräsentation (Modul PRES) durch den Consultant, der den Test geleitet hat.

Nur durch diese Offenheit ist eine positive Wahrnehmung von Sicherheitstests bei Ihren Mitarbei-tern möglich.

Flexibilität

Bei der Durchführung von Tests arbeitet die SySS GmbH nicht nach einem festen Schema, sondernflexibel. Ein festes Schema wäre eine Verkennung der Natur eines Angriffs, denn jedes Netz istanders und jeder Schritt während des Tests hängt vom vorherigen ab. Zusätzlich sind sinnvolleSchwerpunktänderungen während des Tests durch ein Gespräch zwischen Ansprechpartner unddem durchführenden Consultant möglich.

Qualitätssicherung

Die Qualitätssicherung der Berichte wird immer von einem weiteren Consultant mit Testerfahrungvorgenommen. Damit wird auch die Nachvollziehbarkeit der Testergebnisse gewährleistet. Fallsmöglich, kann dies auch bereits während eines Tests geschehen. Zudem sichert das Lektorat derSySS GmbH die sprachliche Qualität des Berichts.

Expertenmeinungen

In den Abschlussberichten von Penetrationstests werden Feststellungen stets bewertet. Die Ex-perten der SySS GmbH sind ausgezeichnet ausgebildet und erfahren, sie diskutieren in strittigenFällen die Sachverhalte untereinander und geben ihren erworbenen Erfahrungsschatz regelmäßigan ihre Kollegen weiter. Um die Neutralität unserer Berichte und Gutachten nicht zu beeinflussen,nimmt die Geschäftsführung der SySS GmbH keinen Einfluss auf die Gutachten der Consultants.Der Consultant bewertet immer nach bestem Wissen und Gewissen. In seltenen Fällen kommt esvor, dass die SySS-Consultants bei der Bewertung von Schwachstellen keinen Konsens finden.Dies beruht nicht auf fehlender Expertise oder nicht zu Ende gedachten Schlüssen, sondern aufverschiedenen Anschauungen oder auch auf unterschiedlichen Betrachtungsweisen der Benutzer.Diese Meinungsvielfalt kommt nicht ausschließlich bei den Consultants der SySS GmbH vor.Ein Beispiel für eine typische unterschiedliche Bewertung seitens der IT-Sicherheitsexperten sindVerschlüsselungslösungen. Während die eine Gruppe von Consultants die strikte End-to-End-Verschlüsselung als ideal ansehen, legt die andere mehr Wert darauf, den Nutzer bestmöglich vorschädlichen Inhalten zu schützen – jedoch ohne eine strikte End-to-End-Verschlüsselung.

1.1.8 Werkzeuge

Sowohl der genaue Ablauf eines Tests als auch die Auswahl der Werkzeuge liegt in der Verant-wortung des testenden Consultants. Dieser passt auf der Basis seiner Erfahrung den Ablauf anden Testgegenstand und insbesondere an die Testtiefe an und wählt die optimalen Werkzeuge aus.Sowohl die Qualität und Nutzbarkeit als auch die Lizenzbedingungen einer Soft- oder Hardwarekönnen sich kurzfristig ändern. Die folgenden Angaben haben beispielhaften Charakter.

Die folgende Übersicht ist daher auch nur eine Auswahl an Werkzeugen, die zum Beispiel beiden Modulen INTERNET und LANWAN eingesetzt werden können:

• Für System- und Diensterkennung werden Portscanner wie Nmap, Unicornscan oderWolpertinger eingesetzt.

• Als automatisierte Schwachstellenscanner kommen Nessus und Saint in Frage.• Für die weitere Überprüfung einzelner Dienste steht eine sehr große Anzahl von Werkzeugen

zur Verfügung, wie beispielsweise Relayscanner, Smtpmap/Smtpscan, Ike-Scan, Dnswalk

und die Hping-Familie.• Manuelle Überprüfungen werden von Telnet, Netcat, Socat, OpenSSL und Stunnel

unterstützt. Auch das Metasploit Framework ist ein ständiger Begleiter bei diesen Test-modulen.

Für Webapplikationstests setzt die SySS GmbH Proxy-Tools wie die Burp Suite Professional,den Charles Proxy oder Webscarab ein. Zum Test von WLANs setzt die SySS GmbH vorallem Kismet, Aircrack/Aircrack-ng, Airreplay-ng, Airodump sowie Karma, Netstumbler,Hostapd und AirMAGNET ein, teilweise mit eigenen Anpassungen.

Die Entscheidung, welche Werkzeuge genau eingesetzt werden, basieren zum einem auf demzu erwartenden Erkenntnisgewinn und zum anderen auf der Testtiefe. Nicht jedes Werkzeugist für jede Software einsatztauglich. Der Einsatz eines jeden Werkzeuges hat eine bestimmteMindestlaufzeit; überschreitet diese den geplanten Testzeitraum jedoch erheblich, muss auf denEinsatz verzichtet werden. Falls der geplante Testzeitraum es zulässt, können aber auch Werkzeugezum Einsatz kommen, die beispielsweise erst nach Testbeginn veröffentlicht wurden.

1.2 Standard-Testphasen

Ein Sicherheitstest besteht aus einem Rahmenprojekt, Standard-Testphasen und einzelnen Test-modulen. Die folgende Grafik verdeutlicht die Gestaltungsmöglichkeiten, indem die Standard-Testphasen rot und die Testmodule blau dargestellt werden:

KICKOFFKick-Off

MODULAnalyse von Schwachstellen und Sicher-heitslücken

DOCUDokumentation samt technischer undsprachlicher Qualitätssicherung

PRESPräsentation und Maßnahmenworkshop

RETESTNachtest

PERIMInventarisierung Ihrer im Internet erreichbaren Systeme

INTERNETAnalyse Ihrer Systeme über das Internet

WEBAPPPrüfung Ihrer Web-Applikation

WEBSERVICEDetaillierte Untersuchung Ihrer angebotenen Webservices

LANWANAnalyse Ihrer Systeme aus dem lokalen Netz bspw.Putzpersonal-/Praktikanten-Szenario, Client-Analyse, Targe-ted Attacks, VoIP, VLAN

WLANPrüfung Ihres WLANs

MOBILEDetaillierter Sicherheitstest von iOS- und Android-Gerätensowie Mobile-Device-Management-Lösungen

INDIVIDUALIndividuelle Prüfungen wie Pivot, Citrix, Produkt-/Labortests,organisatorische Vorgaben, etc.

Dieser Abschnitt befasst sich mit den Standard-Testphasen, die in der Regel feste Bestandteileeines Penetrationstests bilden. Die detaillierte Beschreibung der einzelnen Testmodule, die je nachTestgegenstand variieren, finden Sie in Kapitel 2.

1.2.1 KICKOFF: Kickoff

In einer Vorbesprechung (in der Regel telefonisch) wird der Projektablauf besprochen. DerConsultant, der den Test leitet, geht daher mit einem Ansprechpartner des Kunden unter anderemfolgende Themen durch:

• Testzeitraum und Testzeitfenster• Ansprechpartner und deren Erreichbarkeit• Besprechung des Testgegenstandes• Notwendige Voraussetzungen (siehe das jeweilige Modul)• Umgang mit der Erkennung von DoS-Potentialen• Allgemeines zur Durchführung (siehe das jeweilige Modul)• Festlegen der Sprache, in der der Bericht geschrieben werden soll (Englisch oder Deutsch)• Anzahl der Exemplare des Berichts

• Fragen und Wünsche zum Testablauf

Je nach speziellem Testgegenstand und je nach gewählten Modulen gibt es individuelle Abwei-chungen. Wenn von der Durchführung eines Tests, wie bei den einzelnen Modulen beschrieben,abgewichen werden muss, wird dies ebenfalls zu diesem Zeitpunkt besprochen. Die Ergebnissedes Kickoffs werden protokolliert und dem Kunden zeitnah zur Verfügung gestellt.

Tipp von Sebastian SchreiberPrüfen Sie vor dem Kickoff die unter „Mitwirkung des Kunden“ genannten Punkte und Tipps!Je mehr Zeit Sie sich für die Vorbereitung und die Durchführung des Kickoff nehmen, destoeffizienter wird der Test und desto mehr wird er Ihrem Unternehmen nützen!

1.2.2 MODUL: Durchführung der Sicherheitsprüfung (gewählte Module)

Die Durchführung des vom Kunden in Auftrag gegebenen Sicherheitstests wird durch die ge-wählten Module bestimmt. Diese bilden das Kernstück eines jeden Projekts und betten denTestgegenstand in seinen Kontext ein. Die Module geben ganz allgemein vor, welche Voraus-setzungen für die Sicherheitsüberprüfung notwendig sind und wie die Durchführung des Testsgrob verlaufen wird. Dabei fungieren sie als Rahmen des durchzuführenden Sicherheitstestsund geben Ihnen lediglich Anhaltspunkte zum möglichen Ablauf, denn im Detail verläuft jederSicherheitstest individuell gemäß des vom Kunden festgelegten Testgegenstandes.

Die einzelnen, möglichen Test-Module werden in Kapitel 2 ausführlich beschrieben und illustrierendie Vielfalt an Gestaltungsmöglichkeiten für jegliche Sicherheitstests. Durch unsere Erfahrungkönnen wir selbst auf ausgefallene Testanliegen unserer Kunden eingehen. Ebenso ist die Listeder Module dynamisch, denn sie wird stetig erweitert und den gegenwärtigen Anforderungen,Wünschen und Bedürfnissen unserer Kunden angepasst.

1.2.3 DOCU: Dokumentation

Alle Testergebnisse werden am Ende des Projekts in einem Bericht zusammengefasst. Der Berichtumfasst die folgenden Bestandteile:

• Eine Zusammenfassung der Ergebnisse und die Einschätzung des allgemeinen Sicherheits-niveaus („Executive Summary“).

• Eine Liste der festgestellten Schwachstellen mit Risikoeinschätzung und Maßnahmen zurBehebung.

• Eine nachvollziehbare Darstellung des Nachweises jeder erkannten Schwachstelle.• Auszüge aus den Ausgaben der Testwerkzeuge, wo dies sinnvoll erscheint.• Dokumentation von Besonderheiten während des Testablaufs.• Falls explizit gewünscht, Kommunikationsnachweis mit dem Kunden.

Der Kunde teilt dabei mit, wie viele gedruckte Exemplare des Berichts benötigt werden.Der Bericht wird SySS-intern gedruckt und gebunden. Er wird dem Kunden als Einschreiben mitRückschein (auch ins Ausland) verschickt. Zusätzlich erhält der Kunde den Bericht als PDF-Datei.Auf Wunsch erhält der Kunde die beim Test entstandenen Rohdaten (Ausgaben der Testwerk-zeuge) auf CD/DVD. Allerdings werden diese unbearbeitet zur Verfügung gestellt, so werdenbeispielsweise Falsch-Positive aus den Ergebnissen der Schwachstellenscanner nicht entfernt.

Soweit nicht anders vereinbart, löscht die SySS GmbH die Rohdaten drei Monate nach Testendebzw. drei Monate nach einem eventuellen Nachtest.

Der Dokumentationsaufwand ist bei internen Tests (Modul LANWAN) erheblich höher, dainsbesondere das Testvorgehen detaillierter beschrieben werden muss. Die Maßnahmen zurBehebung der Schwachstellen werden zudem mit dem Ansprechpartner während des Dokumen-tationsprozesses besprochen. Dies ist ein Beispiel für eine Liste von Sicherheitsschwächen mitMaßnahmenvorschlägen:

Risiko Feststellung Empfehlung Referenz

H1.1 www.kunde.deKonfigurationsdatei enthält gültigeAnmeldedaten für dasTypo3-Backend

Betroffene Datei vom Serverentfernen oder Zugriff durch ACLunterbinden

2.1.1Seite 7

H2.1 198.51.100.1Der Router verwendet ein vomHersteller gesetztesStandardpasswort

Nutzername und Passwort ändern 3.1.1Seite 19

M1.1 www.kunde.deAnmeldedaten sowie das SessionCookie werden über eineunverschlüsselte Verbindungübertragen

Anmeldedaten und Session Cookiesausschließlich über verschlüsselteVerbindungen übertragen

2.2.2Seite 9

M2.1 198.51.100.111Der SMB-Dienst gestattet lesendenZugriff auf Netzwerkfreigaben

Dienst an der Firewall filtern 3.4.7Seite 29

L1.1 www.kunde.deDie Passwort-Policy erlaubt dieVergabe von trivialen Passwörtern

Passwortrichtlinie überarbeiten 2.3.9Seite 14

I1.1 www.kunde.deDie Anmeldeseite kann zurBenutzerenumeration missbrauchtwerden

Keine Rückmeldung über dieExistenz eines Benutzers geben

2.3.9Seite 13

1.2.4 PRES: Präsentations-Workshop

Die Ergebnisse des gesamten Tests können in Form einer Präsentation mit Workshop-Charakterbeim Kunden vor Ort dargestellt werden. Bewährt hat sich eine zweiteilige Vorgehensweise:

Begonnen wird mit dem Briefing für die Entscheidungsebene („Management Summary“) mit einerDauer von etwa 30 Minuten. Hier werden grundlegende Ergebnisse des Tests auf strategischer undorganisatorischer Ebene besprochen. Für diesen Teil steht auf Wunsch auch der Geschäftsführerder SySS GmbH, Sebastian Schreiber, zur Verfügung.

Der zweite Teil ist ein technischer Workshop, der für Systemverantwortliche und Administratorengedacht ist. An dieser Stelle gibt es die Möglichkeit, tiefgreifende Fragen zu stellen und mög-

liche Lösungsansätze zu diskutieren. Dieser Teil wird von dem leitenden Consultant des Testsübernommen.

1.2.5 RETEST: Nachtest

ZusammenfassungDer Nachtest hat die Aufgabe, die Wirksamkeit der Maßnahmen zur Behebung von Sicherheits-schwächen zu messen, die in vorangegangenen Tests erkannt wurden.

Ausgangslage

Nach der Identifikation der Sicherheitslücken durch einen Test ist deren Behebung fällig. Inder Regel ist hierfür keine besondere Beratungsleistung nötig, dennoch sollten die Ergebnissedieser Maßnahmen zur Behebung verifiziert werden. Aus diesem Grund ist es ratsam, etwa nach2–4 Wochen, aber spätestens nach einem halben Jahr einen Nachtest durchzuführen. Hierbeiwird nicht nach neuen Verwundbarkeiten gesucht, sondern der Status der bereits bekanntenSicherheitslücken untersucht und dokumentiert. Das Vorgehen wird im Vorfeld besprochen.Als Dokumentation wird der bereits erzeugte Bericht des Haupttests zugrunde gelegt und das„Executive Summary“ angepasst.

20 Whitepaper | Mögliche MODULE

2 Mögliche MODULE

2.1 PERIM: Perimetererkennung

ZusammenfassungDie SySS GmbH identifiziert Netze und Systeme des Kunden auf der Basis öffentlich verfügbarerInformationen. Der Kunde erhält eine Übersicht über die firmeneigenen Systeme, die im Internetaktiv sind. Diese kann er für weitere Tests freigeben. Die Perimetererkennung unterstützt interneInventarisierungsmaßnahmen und die Auswahl zu testender Systeme für weitere Module.

Ausgangslage

Als Perimeter bezeichnet man die Gesamtheit aller Systeme eines Unternehmens, die vom Internetaus erreichbar sind. Normalerweise werden Sicherheitstests nur auf IP-Adressen durchgeführt, dievom Kunden vorher (auch mit Unterstützung der SySS GmbH) ausgewählt worden sind. Wenninsbesondere bei großen, international verteilten Netzen des Kunden eine solche Auswahl nichtmöglich ist oder wenn die Netze, die getestet werden sollten, erst identifiziert werden müssen,kann eine Perimetererkennung durchgeführt werden.

Ziel ist es, eine Liste von Netzen zu erstellen, die explizit dem Kunden zuzuordnen sind, zusätzlicheventuelle Fehler in der Zuordnung aufzudecken und gegebenenfalls an dieser Stelle Kandidatenfür einen Test auszuwählen. Letzteres geschieht nach Verifikation durch den Kunden selbst.Dieser hat hierbei auch die Möglichkeit, Fehler in der eigenen Dokumentation zu korrigieren oderDienstleister (ISPs) dazu anzuweisen. Aufgrund rechtlicher Rahmenbedingungen kann hier dieSySS GmbH nicht selbständig agieren, denn es muss auf jeden Fall ausgeschlossen werden, dassDritte beeinträchtigt werden.

Gründe hierfür könnten sein:

• Eine nicht dokumentierte Auslagerung von IP-Adressen an Dritte.• Veraltete oder fehlerhafte Whois-Einträge.• Gemeinsame Nutzung von Systemen mit Dritten (Bsp. Webhosting).

Der Kunde muss daher zu testende Netze und Systeme freigeben.

Quellen für die Perimetererkennung sind neben frei verfügbaren Datenbanken (Whois, DNS)auch das Mail-Routing des Kunden und Inhalte von Webseiten, die eventuell Aufschlüsse überUnternehmensverknüpfungen geben.

Mögliche MODULE | Whitepaper 21

Voraussetzungen

Um Systeme des Kunden von denen Dritter unterscheiden und Ergebnisse mit der kundeneigenenDokumentation abstimmen zu können, sollte auch bei der Perimetererkennung ein Ansprechpart-ner erreichbar sein.

2.2 INTERNET: Analyse aus dem Internet

ZusammenfassungSysteme im Internet werden auf konkrete Sicherheitsschwächen hin geprüft und die von ihnenausgehenden Risiken bewertet. Im Rahmen der Dokumentation wird ein Katalog mit Vorschlägenzur Beseitigung der erkannten Sicherheitsschwächen aufgestellt.

Ausgangslage

Beim Betrieb von Systemen im Internet bestehen mehrere Arten von Risiken. So können Sicher-heitsschwächen in einzelnen Diensten bestehen, die Dritten folgende Möglichkeiten geben:

• Detaillierte Informationen über die Systeme und der eingesetzten Software, die unterUmständen für weitere Angriffe dienlich sind.

• Vertrauliche Daten und Informationen können eingesehen werden, die nicht system- odersoftwarebezogen sind.

• In das System einzudringen und es für eigene Zwecke oder weitere Angriffe zu nutzen.• Daten können manipuliert werden.

Zielsetzung des Tests

Ziel eines Sicherheitstests im Rahmen des Moduls INTERNET ist, die zu testenden Systemeabhängig von der Testtiefe auf die oben genannten Risiken zu prüfen. Konkret geht es hierbei dar-um, Sicherheitslücken aufzudecken und Daten aufzufinden, die von einem nicht eingeschränktenBenutzerkreis (der Internet-Öffentlichkeit) ausgenutzt bzw. ausgelesen werden können. Wie inKapitel „Technische Risiken bei Sicherheitstests“ (siehe Abschnitt 1.1.5 auf Seite 8) beschrieben, istes kein Testziel, Systeme oder Dienste zum Stillstand zu bringen, sondern nur derartige Potentialeaufzudecken.

Im Rahmen des Moduls INTERNET werden Webapplikationen nicht geprüft, dafür ist dasModul WEBAPP vorgesehen. Zudem wird im einfachen Vergleich mit anderen getesteten Netzenein Gesamtüberblick über das festgestellte Sicherheitsniveau erstellt. Eine Werthaltigkeitsanalyseder gefundenen Daten wird nicht durchgeführt, da die Erfahrung zeigt, dass unsere Kunden diesohne Weiteres selbst vornehmen können.

Durchführung

Die Art der Durchführung wird von dem leitenden Consultant bestimmt, läuft jedoch im Nor-malfall nach folgendem Schema ab:

• Überprüfung der vom Kunden zur Verfügung gestellten Daten auf Korrektheit

• Identifizierung von Betriebssystemen und erreichbaren Diensten• Test der erkannten Dienste mit Schwachstellenscannern• Überprüfung der Ergebnisse, Verifizierung von erkannten Sicherheitslücken• Einsatz von Werkzeugen, welche Gebiete abdecken, die von Schwachstellenscannern nicht

berücksichtigt werden• Manuelle Prüfungen• Nachweis von DoS-Potentialen nach Absprache mit dem Kunden

Anhand der vorliegenden Informationen wählen die testenden Consultants die Werkzeuge aus,die den Erfolg des Tests am besten unterstützen. Einige Beispiele finden Sie unter „Werkzeuge“(siehe Abschnitt 1.1.8 auf Seite 15).

Mitwirkung des Kunden

Damit ein Sicherheitstest effizient und mit hohem Nutzen für den Kunden durchgeführt werdenkann, müssen einige Rahmenbedingungen stimmen. Ansonsten wird der Test erschwert oder estreten Verzögerungen auf und dadurch zusätzliche Kosten.

• Die Systeme müssen tatsächlich aus dem Internet erreichbar sein.• Die Adressen der zu testenden Systeme müssen rechtzeitig vor dem eigentlichen Testbeginn

vorliegen.• Bei der Wahl der Testzeit (im Rahmen des Kickoff) müssen Wartungsfenster, Zeitzonenab-

hängigkeiten (beim Test von Systemen im Ausland) und Feiertage beachtet werden.• Innerhalb der oben genannten Testzeit sollten Ansprechpartner tatsächlich erreichbar und

handlungsfähig sein.• Die Ansprechpartner sollten einen Überblick über die internen Zuständigkeiten bei den

getesteten Systemen haben; dies reduziert den Kommunikationsaufwand während des Tests.• IDS/IPS-Systeme sollten die testenden Systeme nicht blockieren.• Die Zuständigkeiten sollten geklärt sein.• Für den Test von Systemen Dritter muss deren schriftliches Einverständnis vorliegen.

Tipps von Sebastian SchreiberStellen Sie vor dem Test sicher, dass die betroffenen Mitarbeiter und Systembetreuer informiertsind, damit der Test positiv aufgenommen wird.

Sie können die Testqualität weiter erhöhen, wenn Sie die eigene Dokumentation über die zutestenden Adressen vor dem Test prüfen lassen.

2.3 WEBAPP: Prüfung von Webapplikationen

ZusammenfassungAusgewählte Webapplikationen werden aus der Benutzerperspektive auf ihre Sicherheit hin getes-tet. Dabei werden Sicherheitslücken gesucht, die auf der eingesetzten Software, ihrer Konfigurationund der Applikationslogik beruhen.

Ausgangslage

Bei Webapplikationen besteht ein hohes Risiko, dass unautorisiert auf Daten Dritter zugegriffenwerden kann, was einem Verlust an Vertraulichkeit gleichkommt. Zusätzlich ist die Interaktion desBenutzers mit der Website relevant, denn besonders durch Cross-Site Scripting (XSS)-Schwachstellenkönnen sowohl externe als auch interne Benutzer gefährdet werden. Auch Schwachstellen, diebösartige Änderungen an der Webapplikation oder deren Elementen ermöglichen, können vorlie-gen. Ähnlich wie bei dem Modul INTERNET bestehen auch hier Risiken durch das EindringenDritter und die Möglichkeit der (unerwünschten) Informationsermittlung.

Eine Besonderheit bei Webapplikationen ist die meist komplexe Abhängigkeit von anderenSystemen, zum Beispiel E-Mail und Datenbanken. Diese können durch Schwachstellen in derApplikation ebenfalls beeinträchtigt werden. Im Fall von Datenbanken können darüber hinaussogar Informationen gewonnen werden. Diese Abhängigkeiten können damit auch von eingesetz-ter Middleware und im organisatorischen Sinn auch von Lieferanten bestehen. Zudem wird dieSicherheit einer Webapplikation nicht allein durch sie selbst, sondern auch durch das verwendeteContent Management System (CMS) bestimmt.

Eine weitere Besonderheit von Webapplikationen ist, dass Sicherheitsprobleme nach deren Be-kanntwerden auch von Laien nachvollzogen werden können. Dies geht oft mit einem Image-Schaden und Vertrauensverlust einher.

Auch bei diesem Testmodul besteht die Aufgabe darin, festzustellen, ob die oben genanntenRisiken vorliegen. Der Bewertung des Risikos einer einzelnen Schwachstelle kommt bei diesemTest eine höhere Bedeutung zu, denn das Vorhandensein eines allgemeinen Problems deutet nichtimmer auf ein spezielles Risiko hin. Ein weiterer Testschwerpunkt behandelt die Frage, ob esmöglich ist, durch die Ausnutzung der typischen Schwachstellen von Webapplikationen Einsichtin Daten Dritter zu erhalten.

Das Sicherheitsniveau der Anwendung wird abschließend eingeschätzt und Maßnahmen zurBehebung eventueller Schwachstellen vorgeschlagen.

Durchführung

Die Durchführung ist bei Webapplikationen stark von deren Funktion und Aufbau abhängig. Einfestes Schema für den Testablauf kann daher nicht aufgestellt werden. Der Ablauf entspricht abergrob dem folgenden Muster:

• Prüfung der Providing Infrastructure:Wird lediglich eine Prüfung der Webanwendung, nicht jedoch auch eine gründliche Analy-se der Providing Infrastructure beauftragt, so werden initial lediglich einzelne Bestandteileeines derartigen Internettests durchgeführt. Hierbei wird insbesondere die Konfigurationder eingesetzten Webserver-Software und SSL-Komponenten analysiert, um konfigura-tive Schwachstellen aufzudecken. Wird die Analyse der Providing Infrastructure explizitgewünscht, so finden zusätzlich Portscans zur Ermittlung weiterer, auf diesen Systemenerreichbarer Dienste statt. Im Anschluss werden sämtliche Dienste einer Schwachstellenana-lyse unterzogen. Hierbei kommen in Abhängigkeit der erreichbaren Dienste unterschiedlicheWerkzeuge zum Einsatz. Schwachstellen-Scanner wie Nessus oder SAINT gehören zumStandard-Repertoire bei derartigen Tests. Ziel dieser Überprüfung ist es, auch Schwachstellenabseits der für die Webapplikation bereitgestellten Dienste zu identifizieren.

• Strukturermittlung und Sitzungsanalyse:Bezüglich des eigentlichen Tests der Webapplikation wird in einer ersten Phase (InformationRetrieval) die Struktur der zu prüfenden Webanwendung analysiert. Hierfür kommen ne-ben verschiedenen automatisierten Methoden (Spider/Crawler) auch manuelle Verfahrenzum Einsatz. Anschließend erfolgt – falls vorhanden – eine Untersuchung des implemen-tierten Sitzungskonzeptes. Im Fokus liegen hierbei grundsätzliche Schwachstellen, welchedie Durchführung von Identitätsdiebstählen ermöglichen könnten. Geprüft werden unteranderem Sitzungsbezeichner, Cookie-Attribute, Session Handling und Pre-Authentication-Schwachstellen.

• Test des Authentifizierungskonzepts:Erfordert die Anwendung eine Benutzeranmeldung, so werden in einem nächsten Schrittmögliche Angriffe gegen das Authentifizierungskonzept eruiert. Hierbei werden nebenrein technischen (z. B. Umgehung der Authentifizierung durch SQL-Injection-Angriffe) auchprogrammatisch-konzeptionelle Schwachstellen (bspw. Möglichkeiten der Benutzerenu-meration, Passwort-Reset-Funktionen, Passwort-Rate-Angriffe, Kontensperrungen usw.)betrachtet. Alle weiteren Tests werden optimalerweise unter Verwendung mehrerer Benut-zerkonten mit – wenn möglich – unterschiedlichen Rollen durchgeführt.

• Prüfung der Eingabevalidierung:Im Vordergrund steht hierbei eine Prüfung der Funktionalität der serverseitigen Payload-Verifikation mittels klassischer Angriffsvektoren (verschiedene Formen des Cross-Site Scrip-ting, SQL-Injection, URL-Injection, LDAP-Injection, XPath-Injection, XML-Injection usw.). Hier-für werden neben manuellen Eingabeprüfungen auch Payload-Manipulationen unter Ver-wendung von Browser-Plugins und Analyse-Proxys, wie z. B. der Burp Suite Professional,durchgeführt. Wo bedingt durch Umfang und Komplexität der Anwendung angebracht,kommen automatisierte Webapplikations-Scanner zum Einsatz, deren Ergebnisse im An-schluss manuell verifiziert werden.

• Analyse der Applikationslogik:In einem weiteren Schritt wird die Applikation auf möglicherweise fehlerhafte Konsistenz-

oder Plausibilitätsprüfungen innerhalb der Anwendungslogik untersucht. Klassische Bei-spiele wären an dieser Stelle die Möglichkeit einer Preismanipulation innerhalb einesShop-Systems, Anfälligkeiten gegen gefälschte Antworten von eingebundenen Drittsys-temen, wie etwa Zahlungsdienstleistern oder unerlaubte Verzweigungen innerhalb derAnwendungslogik, etwa durch Manipulation in den Client verlagerter Logikkomponenten,die beispielsweise über Hidden Fields transportiert werden.

• Reverse Engineering:Optional können vom Server ausgelieferte (auch binäre) Client-Komponenten wie etwa Ja-va-Applets oder Flash-Anwendungen analysiert werden. Hierfür werden spezielle Dekom-pilierer sowie Reverse-Engineering-Techniken eingesetzt. Grundsätzlich wird in Abhängigkeitder getätigten Feststellungen als Proof-of-Concept geeignete Angriffssoftware entwickelt. Zielist hierbei in erster Linie die Verifikation der Feststellungen sowie die Erlangung weitererInformationen oder Berechtigungen.

OWASP Top 10

Bei der Suche nach Schwachstellen orientiert sich die SySS GmbH sehr stark an den jeweilsaktuellen OWASP Top10. Das Open Web Application Security Project (OWASP) veröffentlicht seitvielen Jahren eine Liste der zehn gefährlichsten Risiken bei Webapplikationen. Diese Liste istdynamisch und wird regelmäßig überarbeitet.

Die aktuellen Top10 (2013) umfassen folgende Risiken:

1. Injection2. Broken Authentication and Session Management3. Cross-Site Scripting (XSS)4. Insecure Direct Object References5. Security Misconfiguration6. Sensitive Data Exposure7. Missing Function Level Access Control8. Cross-Site Request Forgery (CSRF)9. Using Components With Known Vulnerabilities

10. Unvalidated Redirects and Fowards

Darüber hinaus wird auch eine Reihe weiterer Schwachstellenklassen geprüft, die entweder nichtin der OWASP Top10 enthalten sind oder seitdem neu veröffentlicht wurden.

Für den Test muss auf jeden Fall die URL der Webapplikation mitgeteilt werden (bezüglichAnmeldedaten siehe unten). Es sollte berücksichtigt werden, dass das verwendete CMS auchmitgetestet wird.

Ansprechpartner

Die Analyse von Webapplikationen unterscheidet sich nicht nur beim Vorgehen erheblich vonanderen Testmodulen. Wie bereits beschrieben, können Sicherheitsprobleme in der Webapplikationauch weitere Dienste, insbesondere Datenbanken und E-Mail-Dienste betreffen.

Daneben kommen Webapplikationen bzw. deren Funktionalität in der Regel nicht aus einer Hand:Die Gestaltung kann in den Händen einer Agentur liegen, das Schreiben der Webapplikationsowohl in den Händen interner als auch externer Programmierer. Die Hardware selbst kannwiederum von einem Webhoster gestellt und auch betreut werden.

Insbesondere zur Behebung der festgestellten Sicherheitsschwächen muss mit denjenigen, diefür die betroffenen Elemente zuständig sind, Kontakt aufgenommen werden. Daher ist es vonsehr großer Bedeutung, die Kontaktdaten der Ansprechpartner zu kennen, um sie entsprechendkontaktieren zu können.

Wenn es keine direkten Ansprechpartner gibt, kann es zu zweierlei Problemen kommen:

• Rückfragen während des Tests, die zur Verifizierung von Sicherheitsschwächen dienen,können nicht beantwortet werden, was wiederum in Verzögerungen resultiert.

• Wenn die Verantwortlichen für ein Projekt nicht bekannt sind, das von einer Sicherheitslückebetroffen ist, dann verzögert sich die Behebung erheblich.

Aus diesem Grund sollte rechtzeitig vor dem Test mit der Klärung der Zuständigkeiten undFeststellung der Verantwortlichen begonnen werden, auch wenn dies im ersten Schritt aufwen-dig scheint. Anschließend sollten die Betroffenen über Termin und Ziel des Tests informiertwerden. Ebenso wie bei anderen Testmodulen können sie auf Wunsch dem Test beiwohnen.Falls Dritte betroffen sind, müssen diese der Durchführung des Tests zustimmen (in Form einerEinverständniserklärung). Zusätzlich sollte während des Tests ein Ansprechpartner, der mit derWebapplikation aus Benutzerperspektive vertraut ist, für Rückfragen zur Verfügung stehen.

Die Tests erfolgen stets in enger Zusammenarbeit mit den Ansprechpartnern. Hierdurch wirdzum einen garantiert, dass eventuell auftretende Verfügbarkeitsprobleme zeitnah erkannt undausgeräumt werden können und zum anderen, dass vor allem die kritischen Schwachstellen sofortbehoben werden können.

Abhängigkeiten

Organisatorische und technische Abhängigkeiten sollten der SySS GmbH mitgeteilt werden. Dieskann im Rahmen des Kickoff geschehen.

Status der Webapplikationen

Die zu testenden Funktionen müssen möglichst durchgängig verfügbar sein. In einer sehr frühenoder mittleren Umsetzungsphase einer neuen Webapplikation bringt ein Test keine nachhaltigenErgebnisse. Er kann aber dennoch sinnvoll sein, wenn möglichst früh entscheidungsrelevanteErgebnisse vorliegen müssen.

Anmeldeinformationen

Viele Webapplikationen bieten zusätzliche Funktionen in einem internen Bereich an, der erst nacherfolgreicher Anmeldung sichtbar wird (beispielsweise bei einem Kundenportal).

Für den Test dieser Funktionen benötigt die SySS GmbH mindestens zwei Benutzerkontenaus unterschiedlichen Berechtigungsstufen, aus deren Sicht der Test durchgeführt werden soll.Stehen keine entsprechenden Konten zur Verfügung, kann ein Test nur aus der Perspektive eines

Besuchers der Webseite durchgeführt werden. Dies führt meist zu keinen Erkenntnissen bezüglichdes Sicherheitsniveaus der Webapplikation. Um sinnvolle Ergebnisse zu erhalten, dürfen dieRechte der Benutzerkonten gegenüber denen regulärer Anwender nicht eingeschränkt sein. Wiediese Konten erzeugt werden, wird beim Kickoff besprochen.

Testdaten oder Testsystem

Falls der Test nicht an produktiven Daten oder Systemen durchgeführt werden soll, kann auchmit einem Produktivsystem mit Testdaten oder nur mit einem Testsystem gearbeitet werden.Testdatensätze, auf die die für den Test verwendeten Benutzerkonten zugreifen können, solltenbereits vor dem Testbeginn zur Verfügung stehen.

Bei der Arbeit mit reinen Testsystemen ist das Ergebnis des Sicherheitstests nur aussagekräftig,wenn ihre Funktionalität zu großen Teilen mit der des Produktivsystems übereinstimmt.

Sollte keine Möglichkeit zur Bereitstellung einer Testinstanz gegeben sein, so wird die Vorgehens-weise entsprechend justiert. Beispielsweise soll dadurch verhindert werden, dass die Benutzereiner zu testenden, produktiven Webapplikation Verfügbarkeitsbeeinträchtigungen während desTests ausgesetzt sind. Insbesondere die automatisierten Schwachstellen-Scans werden in einemsolchen Fall sehr moderat konfiguriert oder nur bei ausgewählten Funktionen eingesetzt.

Tipps von Sebastian SchreiberUm bei einem Webapplikationstest festgestellte Schwächen zu beseitigen, benötigen Sie dieKooperationsbereitschaft des Verantwortlichen für das betroffene Element. Versuchen Sie, alleZuständigen und Betroffenen daher frühzeitig festzustellen und zu informieren – nur so wirdeine schnelle Reaktion gewährleistet.

Unterrichten Sie alle Beteiligten, auch diejenigen, die beim Test selbst keine aktiven Aufgabenhaben. So schaffen Sie zusätzliches Vertrauen in die Dienstleistung Sicherheitstest und stärken diePosition der IT-Sicherheit im Unternehmen.

Stehen uns für den Test keine Anmeldeinformationen zur Verfügung, dann ist meist ein nur sehrwenig aussagekräftiger Test möglich.

Testwerkzeuge

Schwachstellen-Scannern, auch solchen, die für den Test von Webapplikationen vorgesehen sind,kommt bei diesem Testmodul eine eher unterstützende Funktion zu, da sie nicht in der Lage sind,kontextbezogene Informationen zu verwerten und zu beurteilen.

Dennoch kann die Untersuchung von Webapplikationen durch den Einsatz von Security-Scannernbzw. entsprechenden Proxys unterstützt werden. Hier können unter anderem Nessus, Saint,Metasploit, SQLmap und Burp Suite Professional.

Security-Scannern sind jedoch massive Grenzen gesetzt, daher ist das Hauptwerkzeug bei derUntersuchung von Webapplikationen immer ein Internet-Browser, mit dem manuelle Prüfun-gen durchgeführt werden. Für Firefox (Mozilla) steht eine große Auswahl an Add-Ons zurVerfügung, daher wird er bevorzugt eingesetzt.

Zusätzlich werden zur tatsächlichen Verifizierung von Schwachstellen Werkzeuge (z. B. Skripte)bei Bedarf erzeugt.

Exemplarische Verwundbarkeiten

Die folgenden aufgezählten Schwachstellen beschreiben exemplarische Verbundbarkeiten anWebapplikationen.

• Parametermanipulationen

Wenn innerhalb einer Webanwendung Parameter an Skripte usw. über die URL übergebenwerden, können diese manipuliert werden. Es können dann unter Umständen sowohlunerwünschte Eingaben (z. B. Datenmanipulation von Preisen) vorgenommen als auch Linksfür Phishing konstruiert werden.

Beispiele:

– In einer Webanwendung wird die folgende URL verwendet:http://www.shop.com/shoppingcart.asp?Action=Buy&type=special&price=200

Der Preis könnte editiert werden und dadurch eine URL-Manipulation durchgeführtwerden.

– Werden andere Teile der Webseite über URL-Parameter angesprochen, wie z. B. bei derfolgenden URL (A), dann können über Änderungen eventuell andere Seiten nachgela-den werden (B):

A: http://www.shop.com/index.php?ses=xd67u&url=/specials.html

B: http://www.shop.com/index.php?ses=xd67u&url=www.preparedsite.com

– Ist es möglich, über die Angaben von Pfaden in der URL Dateien auf dem Webservereinzusehen, so liegt eine Local File Inclusion-Verwundbarkeit vor, bei der zudem Path-bzw. Directory Traversal zum Einsatz kommen kann:http://www.shop.com/default.pl?../../boot.ini

– Ist es möglich, über die URL Betriebssystemkommandos auszuführen, dann liegt eineOS Command Injection vor:http://www.shop.com/default.pl?angebote;uptime

An dieser Stelle ist es unter Umständen notwendig, die Eingaben zu kodieren, damit dieseausgeführt werden können.

Die Tragweite von Parametermanipulationen hängt ganz von der jeweiligen Anwendung ab.Daher wird das Risiko durch die SySS GmbH individuell bewertet. URL-Manipulationenverlangen aber als Werkzeug nur einen Web-Browser und keine Spezialkenntnisse, daherbesteht stets ein hohes Risiko, dass sie auch ausgenutzt werden.

• XSS-Schwachstellen

Werden Eingaben in Formularfeldern oder anderen veränderbaren Parametern serverseitignicht validiert, so kann über diese Code eingeschleust werden, der im Kontext andererBesucher zur Ausführung gelangt. Diese Angriffsform wird Cross-Site Scripting – kurz XSS –genannt, da durch den injizierten Code weitere Code-Fragmente von einem fremden Servernachgeladen werden können. Grundsätzlich wird hierbei zwischen zwei verschiedenenFormen des XSS unterschieden: Reflected und Persistent XSS.

Bei Reflected XSS wird der Angriffsvektor, der den auszuführenden Code enthält, üb-licherweise in einem URL-Parameter untergebracht. Dieser Parameter fließt serverseitig indie Generierung einer dynamischen Webseite mit ein und der eingefügte Code kommt beimAufruf der URL durch einen Besucher in dessen Webbrowser zur Ausführung.

Beispiel für Reflected XSS:

Wird die URL einer Webseite aufgerufen, die einen verwundbaren Parameter (hier: „user“)enthält, der serverseitig nicht ausreichend validiert, jedoch in die dynamisch generierteWebseite eingebaut wird, so wird der an diesen Parameter übergebene Code ausgeführt. Indiesem Beispiel öffnet sich eine Javascript-Box, welche den Text „XSS“ enthält:http://www.seite.de/login.php?user="><script>alert(’XSS’)</script>

Derartig manipulierte URLs werden häufig in Form betrügerischer E-Mails verbreitet.

Dies ist bei Persistent XSS-Schwachstellen nicht nötig, da der Code dauerhaft serverseitiggespeichert und bei jedem Aufruf der betroffenen Webseite ausgeführt wird. Das Grundpro-blem bleibt jedoch das gleiche: von Benutzern änderbare Parameter werden nicht ausreichendgefiltert.

Persistent XSS-Schwachstellen sind häufig in Benutzerprofilen oder Kommunikationsfunk-tionen von sozialen Netzwerken oder kommentierbaren Blog-Beiträgen anzutreffen.

Beispiel für Persistent XSS:

Eine Webanwendung erlaubt es den Benutzern, Kundendaten zu verwalten. Bei der Eingabevon Kommentaren zu einem Kunden (z. B. „nicht vor 10 Uhr anrufen“) wird diese nichtvalidiert und Folgendes ist daher als Eingabe möglich:"><script>alert(’XSS’)</script>

Ruft nun ein weiterer Benutzer die Daten des Kunden auf, dessen Kommentarfeld entspre-chend manipuliert wurde, so erhält er ein Pop-Up-Fenster, das den Text „XSS“ enthält.

Beim Auftreten von XSS-Schwachstellen kann abhängig von der zur Verfügung stehendenTestzeit geprüft werden, inwieweit komplexere Eingaben möglich sind, die zum BeispielSession-Diebstahl (siehe unten) erlauben. Dies ist nicht immer möglich, daher wird das vonXSS-Schwachstellen ausgehende Risiko von der SySS GmbH individuell bewertet.

Unter Umständen können XSS-Schwachstellen von Security-Scannern gefunden werden,die dazu in Formularfeldern vordefinierte Eingaben vornehmen. In vielen Fällen ist diesaber nur durch Anpassungen an den Eingaben möglich, die Security-Scanner nicht leistenkönnen – hier ist Handarbeit vonnöten.

• SQL-Injection

Bei der Structured Query Language (SQL) handelt es sich um eine Abfragesprache für re-lationale Datenbanken. Diese Datenbanken übernehmen in vielen Webapplikationen dieAufgabe, Informationen zu speichern. Anwender fragen über entsprechende Eingabefelderdie Datenbank ab und die Ergebnisse werden von der Anwendung aufbereitet. Erfolgt keineausreichende Prüfung der Eingaben, so können Anfragen direkt in SQL an die Datenbankgestellt werden; dies wird als SQL-Injection bezeichnet.

Innerhalb dieses Kontextes ist zu prüfen, inwieweit darüber Inhalte ausgelesen werdenkönnen, die der entsprechende Benutzer anhand seiner Rechte nicht lesen dürfte oder obManipulationen an der Datenbank möglich sind.

Beispiel:

Eine Anwendung bietet eine Suchmaske an, über die es unter anderem möglich ist, Benutzernach ihrem Standort zu suchen. Dabei wird intern der folgende Befehl verwendet, umbeispielsweise die Abfrage nach dem Standort „London“ zu bearbeiten:SELECT * FROM user WHERE location=’London’

Da Eingaben nicht überprüft werden, wird folgende Suchabfrage direkt in den Suchbefehleingebaut:London’;DROP TABLE User --

Der resultierende Befehl lautet folglich:SELECT * FROM user WHERE location=’London’;DROPTABLE User --’

Das Kommando „DROP TABLE“ löscht nun die Tabelle „User“ aus der Datenbank. DieKommentar-Zeichenfolge „--“ wird verwendet, um Befehle, die danach getätigt werden, zuignorieren. Derartige zerstörerische Abfragen werden bei Sicherheitstests nicht generiert,verdeutlichen aber das enorme Risiko, das von SQL-Injection-Schwachstellen ausgehenkann.

SQL-Datenbanken werden auch für die Authentifizierung der Benutzer an der Anwendungselbst verwendet. Werden an dieser Stelle die Eingaben nicht ausreichend geprüft und kön-nen daher SQL-Befehle direkt eingegeben werden, kann der Authentifizierungsmechanismuseventuell komplett umgangen werden.

Beispiel:

Folgender Befehl wird intern zur Authentifizierung verwendet:SELECT permission FROM users WHERE user= ’$user’ AND pass=’$pass’

Sofern der Inhalt der Variable „$user“ ungefiltert in den SQL-Befehl eingebracht werdenkann, ist eine Umgehung der Authentifizierung möglich. Die folgende Eingabe führtdazu, dass der Benutzername „mustermann“ von der Anwendung akzeptiert (und nichtverworfen) wird:mustermann’ OR ’1’=’1

Die vollständige, an die Datenbank gestellte Abfrage hat nun die folgende Form:SELECT permission FROM users WHERE user=’mustermann’ OR ’1’=’1’ AND

pass=’$pass’

Die ursprüngliche Anfrage verlangt, dass sowohl Benutzername als auch Passwort ange-geben werden. Das durch die Manipulation eingefügte logische „OR“ macht diese letzteBedingung optional: falls der Benutzername in der Datenbank vorhanden ist, so ist dieAuthentifizierung erfolgreich.

Derartige SQL-Injection-Schwachstellen, die es erlauben, die Benutzerauthentifizierung voll-ständig zu umgehen, stuft die SySS GmbH als hohes Risiko ein. Sie kompromittieren dieSicherheit einer Anwendung vollständig.

• Session-Diebstahl

Kontrolliert wird, ob es möglich ist, Zugriff auf eine authentifizierte Session eines drittenBenutzers zu erhalten und damit dessen Identität innerhalb der Anwendung zu übernehmen.Gesteuert wird der Zugriff auf eine Anwendung mit einer Session-ID. Diese kann in Formeines Cookies lokal auf der Festplatte des Anwenders gespeichert sein oder bei jedem Aufrufin der URL oder als verstecktes Formularfeld übergeben werden.

Beispiel:

Eine per URL übermittelte Session-ID könnte wie folgt aussehen:http://www.example.net/view/7AD30725122120803

Die Session-ID eines Benutzers kann vor allem durch XSS-Angriffe gestohlen werden. Überdie XSS-Schwachstelle werden speziell vorbereitete Befehle (z. B. JavaScript-Code) voneinem dritten System geladen und im Browser des Benutzers ausgeführt. Diese lesen seineSession-ID aus und leiten sie weiter. Der betroffene Benutzer muss dabei beispielsweise nureinen modifizierten Eintrag in einem sozialen Netzwerk oder eine Beschreibung in einerProduktdatenbank im Webbrowser betrachten. In der Regel ist dem Benutzer nicht bewusst,dass er Opfer eines XSS-Angriffs wird.

Resultat eines erfolgreichen Session-Diebstahls ist daher in der Regel die Übernahme derIdentität des betroffenen Benutzers innerhalb der Anwendung. Die SySS GmbH stuft dahereinen möglichen Session-Diebstahl als hohes Risiko ein.

2.4 WEBSERVICE: Prüfung von Webservices

ZusammenfassungAusgewählte Webservices werden aus unterschiedlichen Testperspektiven auf Sicherheitsschwä-chen hin analysiert, die es einem Angreifer ermöglichen, die Vertraulichkeit und Integrität vonDaten zu gefährden oder die Verfügbarkeit der bereitgestellten Webservice-Funktionalität zustören.

Ausgangslage

Wie bei klassischen Webapplikationen (siehe Modul WEBAPP) besteht auch bei Webservices einhohes Risiko, dass auf nicht autorisierte Weise auf Daten zugegriffen werden kann, was einenVerlust der Vertraulichkeit bedeutet. Darüber hinaus besteht die Gefahr, dass Daten auf nichtautorisierte Weise manipuliert werden können, wodurch deren Integrität verletzt wird. Darüberhinaus stellt die Störung der Verfügbarkeit von Webservices (Denial of Service) oftmals ebenfalls einhohes Risiko dar, da kritische Geschäftsprozesse ohne entsprechende Webservice-Funktionalitätnicht mehr ordnungsgemäß funktionieren.

Webservices, die in der Regel SOAP-basiert oder RESTful sind, nutzen verschiedene Web-Technologien und Protokolle, die auch bei klassischen Webapplikationen zum Einsatz kommen.Neben typischen Schwachstellen in Backend-Anwendungen, wie beispielsweise Buffer Overflowoder SQL-Injection-Schwachstellen, existieren ferner Webservice-spezifische Sicherheitsschwä-chen, wie etwa SOAPAction Spoofing, Webservice Address Spoofing oder Replay-Angriffe, die fürWebservices ein Sicherheitsrisiko darstellen können.

Im Rahmen des Sicherheitstests wird der ausgewählte Webservice aus unterschiedlichen Perspek-tiven auf Schwachstellen geprüft. Je nach Testschwerpunkt und Funktionalität des Webservices,

beispielsweise im Kontext von Business-to-Consumer(B2C)- oder Business-to-Business(B2B)-Geschäftsprozessen, kann der Fokus auf unterschiedliche Schutzziele (z. B. Vertraulichkeit, Ver-fügbarkeit, Integrität) gelegt werden.

Durchführung

Die Durchführung des Sicherheitstests bei Webservices richtet sich primär nach den eingesetztenTechnologien (SOAP-basiert oder RESTful) sowie der bereitgestellten Funktionalität, die in derWebservice-Spezifikation dokumentiert ist.

Der Testablauf entspricht in der Regel dem folgenden Muster:

• Analyse der Webservice-Spezifikation

• Bedrohungsanalyse zur Identifikation möglicher Angriffe, beispielsweise zu– dem unautorisierten Zugriff auf fremde Daten oder– der unautorisierten Manipulation fremder Daten

• Überprüfung von Schwachstellen in Backend-Systemen (z. B. Buffer Overflow, SQL-Injection,XML-Injection)

• Überprüfung Webservice-spezifischer Schwachstellen (z. B. SOAPAction Spoofing, WebserviceAddress Spoofing, Replay-Angriffe)

• Überprüfung der Zugriffskontrolle/Sitzungsverwaltung (sofern vorhanden)• Suche nach Fehlern in der Anwendungslogik bereitgestellter Funktionen

Für die Durchführung der Sicherheitsanalyse werden sowohl spezielle Software-Tools als auchmanuelle Prüfmethoden eingesetzt.

Für den Sicherheitstest eines Webservice muss dessen URL sowie dessen Spezifikation bereitge-stellt werden.

Ansprechpartner

Die Sicherheitsanalyse von Webservices entspricht im Wesentlichen derjenigen von Webapplikatio-nen, weshalb dieselben organisatorischen und technischen Aspekte zu berücksichtigen sind (sieheModul WEBAPP). Die Klärung von Zuständigkeiten sowie die Feststellung verantwortlicherPersonen sollte rechtzeitig vor einem geplanten Sicherheitstest geschehen. Ferner sollten alleProjektbeteiligten vorab über den Termin und das Ziel des Tests informiert werden. Während desProjektzeitraums sollte zudem ein Ansprechpartner für Rückfragen bezüglich des zu testendenWebservices zur Verfügung stehen.

Abhängigkeiten

Die festgestellten organisatorischen und technischen Abhängigkeiten sollten der SySS GmbHmitgeteilt werden. Dies kann im Rahmen des Kickoff geschehen.

Anmeldeinformationen

Sollte für die Nutzung des zu testenden Webservices eine Zugriffskontrolle implementiert sein,benötigt die SySS GmbH mindestens zwei Benutzerkonten pro Berechtigungsstufe, aus derenPerspektive der Sicherheitstest durchgeführt werden soll. Stehen keine entsprechenden Anmel-dedaten zur Verfügung, kann ein Test nur aus der Perspektive eines externen Angreifers ohnegültige Anmeldedaten erfolgen. Aus einer solch eingeschränkten Testperspektive heraus könnenSicherheitsschwächen in einem authentifizierten Kontext eines Webservices in der Regel nichtgefunden werden.

Testdaten/Testsystem

Wie auch bei Sicherheitstests von Webapplikationen gilt bei der Analyse von Webservices, dasssowohl produktive Systeme mit entsprechenden Nutzdaten als auch reine Testsysteme mit Test-daten im Rahmen der Sicherheitsanalyse untersucht werden können. Testdatensätze, auf welchedie für den Sicherheitstest bereitgestellten Benutzerkonten zugreifen können, sollten bereits vorTestbeginn eingerichtet sein.

Darüber hinaus ist bei der Arbeit mit reinen Testsystemen zu beachten, dass Ergebnisse desSicherheitstests nur dann aussagekräftig sind und auf das produktive System übertragen werdenkönnen, wenn ihre Funktionalität zu großen Teilen identisch ist.

2.5 LANWAN: Sicherheitstest im internen Netz

ZusammenfassungSysteme in lokalen Netzen werden auf konkrete Sicherheitsschwächen hin geprüft und die vonihnen ausgehenden Risiken bewertet. Im Rahmen der Dokumentation wird ein Katalog mitMaßnahmen zur Beseitigung der erkannten Sicherheitsschwächen erstellt. Schwerpunkt ist dieFeststellung von Sicherheitslücken, die ein hohes Innentäter-Potential haben.

Perspektive vor Ort

Bei einem klassischen Test des internen Netzes können zwei Perspektiven eingenommen werden:

Zum einen ist es möglich, die Position eines Benutzers mit Zugang zum internen Netz einzuneh-men („Putzpersonal-Szenario“). Systeme werden dann in einem ähnlichen Verfahren wie beimexternen Test auf Sicherheitslücken hin untersucht. Zum anderen kann die Position des Nutzerseines bestimmten Systems eingenommen werden („Praktikanten-Szenario“). In diesem Fall wirdgeprüft, inwieweit das System (z. B. ein Referenz-Client für die jeweilige Nutzergruppe) gegenManipulationen geschützt ist und ob es für Angriffe verwendet werden kann. Aufgrund derenormen Anzahl an testbaren Diensten, die es typischerweise in internen Netzen gibt, kommt derAuswahl sinnvoller Stichproben eine sehr hohe Bedeutung zu. Dies sollte beim Kickoff unbedingtbesprochen werden.

Zusätzlich zu diesen beiden Szenarien können auch individuelle Prüfungen oder Analysenbestimmter Komponenten der internen IT-Infrastruktur durchgeführt werden. Mögliche Beispiele,wie VoIP- oder VLAN-Untersuchungen, werden weiter unten aufgeführt.

Im Folgenden werden generelle Aspekte, die es bei der Durchführung eines LANWAN-Tests zubeachten gilt, erläutert.

Besonderheiten

In internen Netzen kann eine Vielzahl von Diensten und Protokollen zum Einsatz kommen. DieKompetenz der SySS GmbH liegt dabei im Test von IP-basierten Systemen in Ethernet-Netzen.

Bei sehr großen oder sehr komplexen internen Netzen kann die SySS GmbH bei der Auswahlgeeigneter Stichproben helfen und gegebenenfalls auch eine Inventarisierung durchführen, diegrob der Perimetererkennung (siehe Modul PERIM) entspricht.

Ausgangslage

Im Gegensatz zu Systemen im Internet, denen ein Risiko von einem nicht einzuschränkendenBenutzerkreis droht, geht es im internen Netz (Corporate Network) um das Risiko, das vonInnentätern ausgeht. Konkret ist damit ein Benutzer mit Zugang zum internen Netz gemeint.Dieser hat aufgrund seiner Position automatisch einen höheren Kenntnisstand über das Netz.Dies trifft auch auf Besucher eines Gebäudes zu.

Des Weiteren geht ein Risiko von der versehentlichen Einschleppung von Malware (MaliciousCode) aus. Malware kann Sicherheitslücken automatisiert ausnutzen. Zusätzlich ist das Risikohöher, wenn der PC von Benutzern direkt für Angriffe verwendet werden kann.

Ziel ist, je nach eingenommener Perspektive (siehe oben), die etwaig vorhandenen Risiken aufzude-cken, zu bewerten und Vorschläge zur Behebung aufzuführen. Konkret muss bei nachgewiesenenSicherheitslücken das Innentäter-Potential eingeschätzt werden. Dabei werden nicht nur reineSicherheitslücken betrachtet, sondern auch Konfigurationen oder die Verfügbarkeit von bestimm-ter Software, die einem Innentäter Ansatzpunkte für einen erfolgreichen Angriff geben könnten.Hierbei wird nicht nur die Verwundbarkeit von einzelnen Systemen eingeschätzt, sondern auchdie Kommunikation von Diensten untereinander, um Man-in-the-Middle-Potentiale festzustellen.

Falls andere Sicherungsmaßnahmen (Update, Konfigurationsänderung, Ersatz) nicht effektivsind, wird vorgeschlagen, dass die betroffenen Systeme intern abgeschottet werden. Die SySSGmbH führt hierbei keine organisatorische Dateizugriffsberechtigungsprüfung durch. DerartigeKontrollen sind oft durch Externe nicht möglich.

Durchführung

Die Durchführung ist an die des Moduls INTERNET angelehnt:

• Prüfung der Systeme auf erreichbare Dienste• Test der Dienste mit automatischen Schwachstellenscannern

• Verifizierung der Ergebnisse• Begleitende und manuelle Prüfungen• Bei Bedarf Prüfung der eingesetzten Protokolle auf Man-in-the-Middle-Potentiale

Eine Sonderform des Sicherheitstests im internen Netz stellt die Prüfung eines PC-Arbeitsplatzes(beschrieben unter „Perspektive vor Ort“) dar. Hierbei wird überprüft, ob direkte Manipulatio-nen an der Hardware möglich sind (Booten von externen Medien) und anschließend, welcheMöglichkeiten das Betriebssystem bzw. die Installation selbst für Manipulationen bietet.

In internen Netzen werden häufig Systeme eingesetzt, die zum einen nicht besonders wider-standsfähig gegen Angriffe sind und zum anderen teilweise weit über ihren durch den Händlerabgekündigten End-of-Life (EOL) hinaus betrieben werden. Das Risiko, dass solche Systeme beimTest abstürzen, ist nicht zu vernachlässigen. Daher ist bei der Prüfung solcher Systeme eine engeKoordination mit dem Ansprechpartner nötig.

Generell empfiehlt die SySS GmbH, Systeme, die ihr EOL erreicht haben oder seit mehrerenJahren nicht mehr gepflegt wurden, nur zu testen, wenn der direkte Nachweis erbracht werdensoll, dass Systeme abzuschotten oder zu ersetzen sind und der entstehende Schaden vom Kundenin Kauf genommen werden kann. Falls möglich, sollten auch für solche Tests Systeme ausgewähltwerden, die keine kritischen Funktionen erfüllen. Eine Haftung für alle aus eventuellen Abstürzenoder anderen Beeinträchtigungen entstehende Schäden wird durch unsere AGB ausgeschlossen.

Für einen internen Test müssen gewisse logistische Voraussetzungen erfüllt werden, vor allem, daein solcher Test keine autarke Dienstleistung ist.

Ansprechpartner

Ein Ansprechpartner sollte während der gesamten Testzeit gut und schnell erreichbar sein. Erkann dem Test gerne beiwohnen. Da der Test vor Ort stattfindet, sollten alle organisatorischenRahmenbedingungen bereits bei Testbeginn erfüllt sein.

Information der Beteiligten

Alle Systemverantwortlichen, Administratoren und anderen betroffenen Mitarbeiter sollten vorBeginn des Projekts über den Test und seine Zielsetzung informiert werden. Ihre Kooperationkann während des Tests nötig sein, ist aber vor allem für die Behebung eventuell gefundenerSchwachstellen von essentieller Bedeutung.

Arbeitsplatz

Für jeden Consultant sollte ein Arbeitsplatz zur Verfügung stehen. Für den Test eines Netzes istFolgendes erforderlich:

• Mindestens ein Netzanschluss (Ethernet) an das zu testende Netzwerk• Stromanschluss für Notebook und Switch (Steckdosenleiste)• Platz für ca. zwei Notebooks, Switch und Unterlagen

• Möglichst ruhige Umgebung

Für den Test eines Referenz-Clients werden Platz und Strom für ein Notebook sowie ein Internet-zugang (Dokumentation und Recherche) benötigt.

Falls Genehmigungen erforderlich sind, um fremde Hardware an dem Arbeitsplatz betreiben zukönnen, sollten sie rechtzeitig vor Testbeginn eingeholt werden.

Zugang zu Gebäuden und Netz

Der Consultant sollte am Testtag das betroffene Gebäude mit seiner Ausrüstung betreten undden oben beschriebenen Arbeitsplatz erreichen und einrichten können. Eventuell notwendigeGenehmigungen sollten daher rechtzeitig beschafft werden.

Falls zudem ein Mechanismus zur Netzwerkzugangskontrolle im Einsatz sein sollte (z. B. 802.1Xmit Client-Zertifikaten), so sollten entsprechende Zugangsdaten für den Consultant vorbereitetund diesem zu Testbeginn übergeben werden.

Tipps von Sebastian SchreiberSie können das Ergebnis eines internen Tests qualitativ aufwerten, wenn Sie die Auswahl der zutestenden Systeme mit sehr viel Sorgfalt vornehmen.

Bei vielen identischen Systemen ist fast immer der tiefergehende Test von zwei als Stichprobenausgewählten Systemen sinnvoller als eine grobe Prüfung aller.

Ziel eines Sicherheitstests ist es, technische Defizite aufzudecken. Informieren Sie daher alleBeteiligten vor Testbeginn, sodass der Test als eine positive, die eigene Sicherheit stärkendeMaßnahme wahrgenommen wird.

2.5.1 Putzpersonal-Szenario (Modul LANWAN/CLEAN)

Wie bereits in Abschnitt 2.5 beschrieben, handelt es sich hierbei um eines der beiden klassischenSzenarien bei internen Sicherheitsanalysen. Der Consultant wird mit einem eigenem Notebook dieSicherheit des Kundennetzwerks analysieren. Ein typischer Ablauf eines solchen Tests gestaltetsich wie folgt:

• Prüfung eventuell vorhandener Netzwerkzugangskontrollen• Ermittlung genutzter interner Netzbereiche• Identifizierung aktiver Systeme und Dienste• Schwachstellenanalyse

Das Ziel dieser Vorgehensweise besteht darin, einen möglichst genauen Überblick über das Sicher-heitsniveau der internen Netzlandschaft zu erhalten. Tests können sowohl in der Breite erfolgen –das heißt, es wird keine Einschränkung bezüglich der zu testenden Systeme getroffen – als auchin der Tiefe. Bei letzterer Vorgehensweise stellt der Kunde eine sinnvolle und repräsentative Listezu testender Systeme zusammen, auf die sich der Consultant dann konzentriert.

Der Consultant wird – je nach Kundenwunsch – Wege aufzeigen, über die er beispielsweise seineBerechtigungen innerhalb des Unternehmensnetzes ausweiten kann, über die er auf vertrauli-che Daten Zugriff erlangen kann oder über die es ihm gezielt gelingt, bestimmte Systeme zukompromittieren.

Tipps von Sebastian SchreiberWenn Sie dem Consultant die intern genutzten Netzbereiche – beispielsweise in Form einesNetzwerkplans – bei Projektbeginn vorlegen, kann wertvolle Zeit eingespart werden, die dannwiederum in die eigentliche Schwachstellenanalyse investiert werden kann.

2.5.2 Praktikanten-Szenario (Modul LANWAN/TRAINEE)

Im Rahmen dieses Szenarios, bei dem es sich um das zweite der beiden klassischen Innentäter-Szenarien handelt (siehe Abschnitt 2.5), wird dem Consultant ein Standard-Client sowie eineBenutzerkennung zur Verfügung gestellt. Aus dieser simulierten Sicht eines Mitarbeiters/Prak-tikanten wird anschließend der Versuch unternommen, sowohl lokal auf dem Client als auchinnerhalb des Netzes die eigenen Rechte auszuweiten. Die Kernelemente dieser Untersuchungsind unter anderem die folgenden:

• Physische Angriffsmöglichkeiten wie Booten von externen Medien• Konfigurationsanalyse• Software-Inventarisierung und Ermittlung des Patch-Standes• Prüfung auf Härtungsmaßnahmen• Lokale Dateisystemanalyse (z. B. NTFS-Zugriffsberechtigungen)• Netzlaufwerke und -freigaben

Tipps von Sebastian SchreiberStellen Sie unserem Consultant einen möglichst realitätsgetreuen Client zur Verfügung, wie erauch einem neuen Mitarbeiter, z. B. einer Praktikantin, bereitgestellt werden würde. Sorgen Siezudem frühzeitig für eine Beantragung eines Test-Benutzerkontos, sodass dieses dem Consultantzu Testbeginn vorliegt. Das Benutzerkonto sollte mit typischen Berechtigungen ausgestattet sein.

2.5.3 Client-Analyse (Modul LANWAN/CLIENT)

Neben dem im letzten Abschnitt beschriebenen Praktikanten-Szenario sind auch weitere, Client-zentrierte Analysen möglich. Ein immer wieder aufkommendes Thema sind beispielsweisegründliche Analysen einer Referenz-Installation, die im Zuge einer Migration von einem älteren(z. B. Windows 7) zu einem neueren (z. B. Windows 8.1) Betriebssystem erstellt wurde. Vor demeigentlichen Rollout wird unser Consultant im Zuge dieser Prüfung eruieren, ob die umgesetztenHärtungsmaßnahmen greifen und ob zusätzliche Schutzinstanzen implementiert werden sollten.Im Grunde wird ein möglicher „Diebstahl“ eines Firmen-Notebooks simuliert, bei dem unteranderem folgende Aspekte betrachtet werden:

• Festplattenverschlüsselung (Pre-Boot Authentication, Virtualisierung, Speicheranalyse usw.)• Boot- und Hardware-basierte Angriffe (Booten externer Medien, PXE, Direct Memory Access-

basierte Angriffe, Cold-Boot-Angriffe)• Systemanalyse (Zugriff auf vertrauliche Daten, Data-Loss-Szenarien, Device Control, Zugriffs-

rechte, Trojanisierung, Konfiguration)• Rechteausweitung (Bordmittel, Betriebssystem- und Software-Schwachstellen, exploits)

• Analyse von Dritt-Software (vor allem Antiviren-Lösung, Endpoint Protection, Software-Verteilung)

• Netzbasierte Analyse (Port- und Security-Scans, manuelle Prüfung, Traffic-Analyse, Ein-dringen in das Firmennetz, z. B. per VPN)

Tipps von Sebastian SchreiberDer ideale Zeitpunkt für die Durchführung einer solchen, gründlichen Client-Analyse ist vordem flächendeckenden Rollout. Dank der beispielsweise in Form von Gruppenrichtlinien zurVerfügung stehenden Möglichkeiten können identifizierte Schwachstellen in der Regel jedochauch nachträglich behoben werden.

2.5.4 Targeted Attacks (Modul LANWAN/TARGET)

Die vergangenen Jahre haben gezeigt, dass Unternehmen immer öfter Opfer von zielgerichtetenAngriffen – Targeted Attacks – werden. Bei diesen Angriffen liegt der Fokus nicht mehr aufder wahllosen Übernahme von Perimetersystemen oder einem Eindringen in die DMZ überwebbasierte Schwachstellen, sondern auf der Kompromittierung ausgewählter Ziele im internenUnternehmensnetz: den Clients. Angreifer machen sich hierfür Techniken wie Social Engineering,Phishing, Spear-Phishing, Whaling oder Waterholing zunutze.

Auf Client-Systemen ist eine Vielzahl von Softwarekomponenten installiert, die beispielsweisevon Browsern in Form von Plugins verwendet und so direkt gestartet werden können. Ebendiese Komponenten stellen – besonders im Falle der Verwendung von veralteten Versionen – einlohnendes Ziel für Targeted Attacks dar. Ein prominentes Beispiel hierfür ist der Adobe Reader

oder die Java-Laufzeitumgebung. Die Übernahme eines oder mehrerer Client-Systeme kann eineweitreichende Kompromittierung des Corporate Network nach sich ziehen und stellt auch im Falleeines Advanced Persistent Threats oftmals den ersten Schritt dar.

Dieser Spezialfall einer internen Sicherheitsprüfung bildet den zielgerichteten Angriff auf einausgewähltes Client-System ab. Die SySS GmbH versucht, durch die Verwendung von bekanntem,angepasstem bzw. eigenem Schadcode das zur Verfügung gestellte Client-System zu übernehmen.Als Nebeneffekt dieser Prüfung wird gezeigt, inwiefern vorhandene Gateway-Security-Lösungendie Durchführung derartiger Angriffe erschweren. Ausgehend von einem Referenz-Client wirdder Consultant eruieren, inwiefern der Kunde gegen diese Angriffsform abgesichert ist. Unteranderem wird Folgendes geprüft:

• Browser- und Browser-Plugins• Dokumentbetrachter und Medienabspiel-Software (z. B. präparierte PDF-Dateien oder

Office-Dokumente)• Dritt-Software wie Java

• Umgehung von Schutzmaßnahmen (z. B. UAC)• Austricksen von Zwischenstationen wie Mail-Filter, AV-Gateways, URL-Filter, Content In-

spection• Malware in E-Mail-Anhängen

Tipps von Sebastian SchreiberTargeted Attacks sollten stets durch unsere Consultants „simuliert“ werden, die dabei sowohl in dieOpfer- als auch die Täterrolle schlüpfen. Social Engineering-Komponenten wie Phishing sollten Sieaus Rücksicht auf Ihre Mitarbeiter vermeiden. Der Consultant wird ausgehend von einem IhrerReferenz-Clients versuchen, den Schadcode von einem eigenen SySS-Root-Server nachzuladen.

2.5.5 VoIP und VLAN (Modul LANWAN/VOIP und LANWAN/VLAN)

Die Voice over Internet Protocol (VoIP) Technik ist in den letzten Jahren für Unternehmen besondersaufgrund langfristiger Kosteneinsparungsmöglichkeiten und wegen einer Vereinheitlichung derIT-Infrastruktur immer mehr in den Vordergrund gerückt. Doch so innovativ und vergleichs-weise preiswert diese Technologie auch ist, sie birgt auch spezifische Bedrohungen mit starkenAuswirkungen auf die Vertraulichkeit, Integrität, Verfügbarkeit und Authentizität übermittelterDaten.

Gerade große, über mehrere Standorte verteilte Unternehmen verwenden Telefonie und E-Mail-Verkehr als Kommunikationsinstrument für teils hochkritische und schützenswerte Informationen.In diesem Zusammenhang ist die Wirtschaftsspionage ein mittlerweile gängiges und äußerst lukra-tives Motiv für Angreifer geworden, die beispielsweise die Wettbewerbsfähigkeit der Konkurrenzin Erfahrung bringen, schwächen oder die eigene stärken möchten.

In diesem Testszenario wird von dem Risiko eines Angreifers mit Zugriffsmöglichkeit auf einenNetzwerkanschluss im Unternehmensnetz ausgegangen. Dabei ist es irrelevant, ob der Angreiferein gültiges Benutzerkonto besitzt und sich in das Netzwerk eingliedern darf oder ob ihm jeglicheZugriffsberechtigung fehlt.

Die SySS GmbH untersucht im Rahmen der Prüfung vor allem die Erfüllung der SchutzzieleVertraulichkeit, Integrität, Verfügbarkeit und Authentizität der übertragenen Sprachdaten. Hierzufokussiert die SySS GmbH die Untersuchung auf den möglichen Mitschnitt von Telefon- sowieKontrollverbindungen, Angriffe gegen andere Identitäten sowie Anrufumleitungsversuche. DesWeiteren werden auch Schwachstellen und Konfigurationen involvierter Systeme gründlichuntersucht.

Bevor allerdings die Schutzziele einer VoIP-Verbindung angegriffen werden können, muss in denmeisten Fällen zunächst der Zugriff auf die Sprachdaten erfolgen können. Dieser erweist sich inder Regel aufgrund einer zumindest auf logischer Ebene erfolgenden Netzwerkseparierung durchVLANs als erste zu bewältigende Hürde. Anhand einer passiven Traffic-Analyse erfolgt daherzunächst die Identifikation von eventuell vorhandenen Schwachstellen beziehungsweise konfigu-rativen Fehlern in der jeweiligen Netzwerkseparierung. Das Ziel dieser VLAN-Untersuchung istdas Erlangen einer Zugriffsmöglichkeit auf das Sprachnetzwerksegment. Im Anschluss daran wirddie Anfälligkeit für die bereits zuvor genannten VoIP-spezifischen Verwundbarkeiten geprüft.

Im Detail werden unter anderem die folgenden Punkte bei der VoIP-Analyse berücksichtigt:

• Passive Traffic-Analyse (Signalisierungs- und Sprachdaten, „One Wire to the Desk“, usw.)• Netzbasierte Angriffe gegen VoIP-Phone und VoIP-Anlage• Angriffe gegen ein VoIP-Phone mit physikalischem Zugriff• Boot-Angriffe, Traffic-Mitschnitt eines Boot-Vorgangs• Lauschangriffe (Man-in-the-Middle, Logging-Funktionen im integrierten Webserver, usw.)

Ferner kann der Fokus der Prüfung auch auf die Netzwerkseparierung via VLANs gelegt werden.Hierbei wird beispielsweise Folgendes geprüft:

• Passive Traffic-Analyse (Information Leaks, usw.)• Prüfung der Abschottungswirkung/Inter-VLAN-Routing• Trunking-Angriffe• Durchlässigkeitsanalyse in andere, auch physikalisch getrennte Netze

Für die Testdurchführung werden seitens der SySS GmbH lediglich zwei standardmäßig konfigu-rierte VoIP-Telefone aus dem Unternehmensbestand benötigt. Eine Übersicht über zum Einsatzkommende VLANs kann dem Consultant ebenfalls zur Verfügung gestellt werden.

Tipps von Sebastian SchreiberÄhnlich wie bei einer Client-Analyse sollten auch bei diesem Testmodul zwei fertig konfigurierteReferenz-VoIP-Phones bereitgestellt werden. Legen Sie unserem Consultant idealerweise einenNetzwerkplan bereit, auf dem sämtliche genutzte Netzsegmente inklusive VLAN-ID dargestelltwerden. Dies spart bei einer Durchlässigkeitsanalyse sehr viel Zeit ein.

2.6 WLAN: Test des Drahtlosnetzwerks

ZusammenfassungDas WLAN des Kunden wird vor Ort auf Sicherheitsschwächen hin untersucht. Zusätzlich wirddie Client-Sicherheit geprüft. Im Rahmen der Dokumentation beschreibt die SySS GmbH das Si-cherheitsniveau des WLAN und unterbreitet Vorschläge zur Behebung von Sicherheitsschwächen.

Die SySS GmbH prüft dabei WLANs nach dem IEEE-Funk-Standard 802.11 auf 2.4 und 5 GHz.Andere Funknetze (basierend auf OWL, OpenAIR, UHF, S-UHF usw.) sind nicht Bestandteil einesWLAN-Tests.

Ausgangslage

WLAN kann – im Gegensatz zu drahtgebundenen Netzen – jederzeit von Dritten erreicht undempfangen werden. Hieraus resultiert die Gefahr des Missbrauches der WLAN-Infrastruktur.Die Bedrohung besteht einerseits in der unberechtigten Nutzung des WLAN und andererseitsin der Ausspähung der übermittelten Daten durch Unbefugte. Dies betrifft dann den Teil desUnternehmensnetzes, welcher per WLAN erreichbar ist.

Um die oben genannten Risiken ausschließen zu können, werden sowohl die Zugangspunk-te (Access Points) als auch die WLAN-Clients (z. B. Notebooks oder Mobiltelefone) untersucht.Gegenstand der Untersuchung sind in erster Linie die eingesetzten Verschlüsselungs- und Au-thentifizierungsverfahren sowie die Client-Konfiguration. Bei dieser wird bei der Untersuchungein Schwerpunkt auf Resistenz gegen Man-in-the-Middle-Angriffe gelegt.

Zusätzlich kann eine Inventarisierung des WLAN erfolgen, wobei auch die Konfiguration über-prüft wird.

Durchführung

Der WLAN-Test findet vor Ort statt. Das genaue Vorgehen hängt stark von der zu testendenLokation und der verwendeten WLAN-Infrastruktur ab. Der Ablauf entspricht in etwa demfolgenden Muster:

• Verifizierung: Entspricht das Vorgefundene den Erwartungen und Informationen?• Erkennung von Zugangspunkten (APs)• Untersuchung der Netze hinsichtlich Authentifizierung und Verschlüsselung• Angriff gegen festgestellte Authentifizierung und Verschlüsselung• Untersuchung der WLAN-Clients

Bei der Untersuchung von Funknetzwerken sind Denial-of-Service-Angriffe zwangsläufiger Be-standteil. Diese können aber auf ausgewählte Systeme (z. B. einen Referenz-Client) beschränktwerden. Eine Auswahl von möglichen Testwerkzeugen wird unter „Werkzeuge“ (siehe Ab-schnitt 1.1.8 auf Seite 15) vorgestellt.

Da WLAN-Tests immer vor Ort stattfinden, sollte wie beim internen Test stets ein Ansprechpartnerzur Verfügung stehen.

Informationen

Vor Beginn des Tests sollten Informationen über die WLAN-Infrastruktur, insbesondere den ein-gesetzten Access- Point-Typ und die Art der Authentifizierung zur Verfügung gestellt werden, ambesten im Rahmen des Kickoff. Des Weiteren sollten alle Beteiligten und Systemverantwortlichenfür das WLAN über den Test und seine Intention informiert werden und während des Tests fürRückfragen zur Verfügung stehen.

Ansprechpartner

Der Ansprechpartner sollte während des Testzeitraums gut erreichbar sein und dem Consultantauch Zugang zu den zu untersuchenden Gebäuden ermöglichen können. Die Erfahrung zeigt,dass es am effizientesten ist, wenn der Ansprechpartner diese Zugangsberechtigungen selbst hatund zusätzlich erteilen kann.

Falls der Consultant Lokationen ohne Begleitung testen soll, sollte pro zu besuchender Örtlichkeiteine Person zugegen sein, die den Zugang zu Gebäuden und zum Gelände ermöglicht und überden Test bzw. Besuch informiert ist. Optional kann der Consultant mit entsprechenden Unterlagenausgestattet werden.

Zugang zu Gebäuden und zum Gelände

Die hierfür erforderlichen Genehmigungen müssen zu Testbeginn vorliegen. Dies betrifft sowohlden Zugang für den Consultant selbst als auch für seine Ausrüstung.

Bei der Wahl des Testzeitraums sollten vor allem Öffnungs- und allgemeine Arbeitszeiten be-rücksichtigt werden. Falls Begehungen nötig sind, sollten diese ausschließlich bei Tageslichtdurchgeführt werden. Wenn WLAN-Clients getestet werden, sollten Referenz-Clients zur Verfü-gung stehen oder Stichproben ausgewählt werden. Sollen mehrere Örtlichkeiten an einem Taggetestet werden, müssen bei der Wahl des Testzeitraums und der Testdauer auch Faktoren wieVerkehrsfluss usw. in Betracht gezogen werden.

Tipps von Sebastian SchreiberBeschaffen Sie die notwendigen Genehmigungen für den Zutritt zu Gebäuden rechtzeitig undinformieren Sie die Beteiligten. So werden lange und unproduktive Wartezeiten vermieden.

Das Informieren der Beteiligten hilft, dass sie den Test als eine positive Maßnahme und nicht alseine störende Kontrolle wahrnehmen. Sollten sich unter Ihren Mitarbeitern Personen befinden,die Bedenken haben, so laden Sie diese einfach ein, dem Test beizuwohnen.

2.7 MOBILE: Sicherheitstest von mobilen Endgeräten und MobileDevice Management

2.7.1 Sicherheitstest von Apple iOS-Geräten

ZusammenfassungAusgewählte Apple iOS-Geräte (z. B. iPhone oder iPad) werden aus unterschiedlichen Perspek-tiven auf Sicherheitsschwächen hin untersucht, die es einem Angreifer ermöglichen, auf nichtautorisierte Weise auf lokal gespeicherte Daten zuzugreifen sowie über das mobile EndgerätZugriff zum Unternehmensnetzwerk zu erlangen.

Ausgangslage

Auf mobilen Endgeräten in Form von Smartphones oder Tablet-PCs werden häufig sensibleInformationen wie etwa personenbezogene Daten oder unternehmenskritische Dokumente (E-Mails, PDF-Dateien etc.) gespeichert. Darüber hinaus bieten solche mobilen Geräte oftmalseinen Zugang zum Unternehmensnetzwerk, um etwa PIM-Funktionalitäten (Personal InformationManagement) nutzen zu können. Dazu gehören beispielsweise die Synchronisation von E-Mails,Kontakten und Terminen. Dieser Umstand macht mobile Endgeräte, wie das Apple iPhone oderdas Apple iPad, zu einem interessanten und auch lohnenswerten Ziel für Angreifer. Da MobileDevices ständig unterwegs eingesetzt werden, erhöht sich das Diebstahlrisiko.

Im Rahmen des Sicherheitstests wird das ausgewählte iOS-Gerät aus unterschiedlichen Perspekti-ven heraus auf Schwachstellen geprüft. Je nach Testschwerpunkt der Sicherheitstests werden dabeiAngriffsszenarien aus der Perspektive eines externen Angreifers und/oder aus der Perspektiveeines autorisierten Benutzers des iOS-Geräts durchgeführt.

Durchführung

Die iOS-Geräte werden im SySS-Labor auf Sicherheitsschwächen hin untersucht. Je nach Test-schwerpunkt kommen dabei unterschiedliche Werkzeuge und Methoden zum Einsatz.

Mögliche Angriffsszenarien für diese beiden Testperspektiven werden im Folgenden aufgeführt:

1. Angriffe aus der Perspektive eines externen Angreifers:a) Angriffe über Netzwerkschnittstellen des iOS-Geräts (WLAN, Bluetooth)b) Angriffe gegen Netzwerkdienstec) Man-in-the-Middle-Angriffe gegen genutzte Apps (E-Mail-Synchronisation, VPN-Zugriff,

Dokumentenverwaltung, etc.)d) Angriffe mit physikalischem Zugriff auf das iOS-Gerät (Diebstahlszenario)

i. Nicht autorisierter Zugriff auf lokal gespeicherte Datenii. Manipulation des iOS-Geräts (bspw. Installation von Schadsoftware)

2. Angriffe aus der Perspektive eines autorisierten Benutzers:a) Zugriff auf Daten fremder Benutzer via PIM-Funktionalitätb) Manipulation des iOS-Geräts (Jailbreak, Installation nicht genehmigter Apps)c) Sicherheitsanalyse ausgewählter Apps (Dokumentenverwaltung, Fernzugriff auf Syste-

me im Unternehmensnetzwerk, Mobile Banking, etc.)

Implementierte Schutzmechanismen, wie etwa das Löschen von Benutzerdaten nach einer be-stimmten Anzahl fehlgeschlagener Anmeldeversuche am iOS-Gerät, die Erkennung von sogenann-ten Jailbreaks oder das Zurücksetzen von Geräten aus der Ferne (Remote Wipe), die beispielsweisevon eingesetzten Mobile-Device-Management-Lösungen bereitgestellt werden, können im Rahmendes Sicherheitstests ebenfalls überprüft werden.

Um den Test eines iOS-Geräts durchzuführen, müssen vor allem logistische Voraussetzungenerfüllt werden. So muss der Transport der iOS-Geräte organisiert werden und wie bei anderenTests auch ein Ansprechpartner für Rückfragen zur Verfügung stehen.

Informationen

Vor Testbeginn sollten Informationen über die zu testende iOS-Hardware, die iOS-Betriebs-systemversion sowie relevante Angriffsszenarien im Rahmen des Kick-Off mitgeteilt werden.Des Weiteren sollten alle Beteiligten wie etwa Systemverantwortliche für Exchange- oder Mobile-Device-Management-Server über den Sicherheitstest informiert werden und innerhalb des Test-zeitraums für Rückfragen zur Verfügung stehen.

2.7.2 Sicherheitstest von Android-Geräten

ZusammenfassungMobile Google Android Endgeräte wie Smartphones oder Tablets und darauf installierte Appli-kationen werden bei dieser Sicherheitsprüfung auf Schwachstellen hin getestet. Android-Appswerden mit Hilfe von (Java)-Decompilern und Debuggern einer statischen und dynamischen Ana-lyse unterzogen. Der Datenverkehr zum Server wird analysiert, die Verschlüsselung im Rahmeneiner Man-in-the-Middle-Attacke versucht aufzubrechen. Neben der Prüfung der über das Interneterreichbaren Server und der Anbindung der Geräte an diese werden die Sicherheitseinstellungenanalysiert und unter Betrachtung des geforderten Schutzbedarfes bewertet.

Ausgangslage

Auf mobilen Endgeräten wie Smartphones oder Tablet-PCs werden häufig sensible Informa-tionen wie etwa personenbezogene Daten oder unternehmenskritische Dokumente (E-Mails,PDF-Dateien etc.) gespeichert. Darüber hinaus bieten solche mobilen Geräte oftmals einen Zugangzum Unternehmensnetzwerk, um etwa PIM-Funktionalitäten (Personal Information Management)nutzen zu können. Dazu gehören beispielsweise die Synchronisation von E-Mails, Kontakten undTerminen. Dieser Umstand macht Google-Android-Endgeräte zu einem interessanten und auchlohnenswerten Ziel für Angreifer. Um diese Mobile Devices in das Unternehmensnetzwerk einzu-gliedern und die darauf gespeicherten Daten den Sicherheitsrichtlinien konform zu verwaltenwird ein sogenanntes Mobile Device Management (MDM) eingesetzt.

Zu dem Modul MOBILE gehört auch die Analyse von Android-Apps. Da bei der Eigenentwick-lung von Apps zahlreiche Sicherheitsmaßnahmen selbst implementiert werden müssen, empfiehltdie SySS GmbH, diese sofort einer Analyse zu unterziehen, sobald personenbezogene Daten oderDaten mit einem hohen Schutzbedarf von der App verarbeitet werden.

Im Rahmen des Sicherheitstests werden nach Absprache Applikationen, welche für Google

Android entwickelt wurden, auf Schwachstellen hin geprüft. Neben der Erfüllung der Sicher-heitsanforderungen wird ebenso der Datenverkehr überwacht. Abschließend schätzt die SySSGmbH das Sicherheitsniveau ein und schlägt Maßnahmen zur Behebung oder Abschwächungeventueller Schwachstellen vor.

Durchführung

Die Android-Geräte werden im SySS-Labor auf Sicherheitsschwächen hin untersucht. Je nachTestschwerpunkt kommen dabei unterschiedliche Werkzeuge und Methoden zum Einsatz. Aufdas Mobile Device wird beispielsweise mit der Android Debugging Bridge zugegriffen, Appswerden dekompiliert und einer statischen Analyse unterzogen.

Für einen Test der Google Android-Mobilgeräte müssen je nach Testszenario folgende Anforde-rungen erfüllt werden:

• Der Kunde muss der SySS GmbH das zu testende Gerät zusenden

• Einsicht in die Profile des Mobile Device Managements

• Die Möglichkeit, Testgeräte selbst in das Mobile Device Management einzugliedern

• Bereitstellung der zu testenden App, falls diese nicht über den App-Store verfügbar ist

Ansprechpartner

Da die Prüfung der Android-Apps im Labor der SySS GmbH durchgeführt wird, sollte derVerantwortliche der zu testenden App als Ansprechpartner innerhalb des Testzeitraums erreichbarsein. Für Detailfragen ist es hilfreich, wenn der Kontakt zu den Entwicklern oder einem anderentechnischen Ansprechpartner besteht.

Abhängigkeiten

Organisatorische und technische Abhängigkeiten sollten der SySS GmbH mitgeteilt werden. Dieskann im Rahmen des Kick-Off geschehen.

Die folgenden aufgezählten Schwachstellen beschreiben exemplarische Verwundbarkeiten, die beiTests des Moduls MOBILE vorkommen.

• Man-in-the-Middle-Angriff auf SSL-gesicherte Verbindung: Da die zu testende Applika-tion in einigen Fällen selbst die Authentizität des Server-Zertifikats verifizieren muss, kannbei nicht ordnungsgemäßer Implementierung der Datenverkehr von einem Angreifer ingeeigneter Position im Netzwerk abgehört und modifiziert werden.

• Anmeldedaten werden im Klartext gespeichert: Die zu testende Applikation und die da-rin abgelegten Zugangsdaten sind besonders schützenswert, da sie für weitere Angriffeeingesetzt werden können. Dennoch ist eine Extraktion der Datenbank möglich, da dieApplikation sich auf die Schutzmaßnahmen des Betriebssystems verlässt.

• Rooting-Erkennung kann umgangen werden: Die zu testende Applikation verfügt übereine Rooting-Erkennung, welche jedoch von einem Angreifer umgangen werden kann. Appli-kationen mit hohem Schutzbedürfnis sollten nicht auf Geräten mit Root-Zugriff ausgeführtwerden, da die Schwachstellen, welche zur Umgehung der Schutzmechanismen des Sys-tems geführt haben, auch von Angreifern ausgenutzt werden könnten. Insbesondere wirddadurch auch das Sandboxing ausgehebelt, welches die Applikation in einer abgeschottetenUmgebung ausführen sollte.

• Sicherheitseinstellungen: Die Sicherheitseinstellungen entsprechen nicht dem gefordertenSchutzbedarf des Kunden. Ein Mitarbeiter kann geschäftliche und private Daten mischen,es werden nur geringe Vorkehrungen gegen Data Loss Prevention unternommen. So bestehtbeispielsweise die Möglichkeit, dass versehentlich Unternehmensdaten im Internet exponiertwerden können.

• Reverse-Code-Engineering: Die App weist keine Schutzmaßnahmen gegen Reverse-Code-Engineering auf. Durch Code Obfuscation (Umbenennung von Klassen- und Methodennamen)besteht die Möglichkeit, den Quelltext für einen Angreifer nur mit erhöhtem Aufwand lesbarzu machen. Ein Angreifer benötigt in diesem Fall signifikant mehr Zeit, um die Applikationzu verstehen.

2.7.3 Prüfung von Mobile Device Management Lösungen

ZusammenfassungDiese Sicherheitsprüfung dient dazu, die mobilen Endgeräte wie Smartphones oder Tablets sowiedie dafür benötigte Infrastruktur, sogenannte Mobile-Device-Management-Lösungen auf Schwach-stellen hin zu testen. Neben der Prüfung der über das Internet erreichbaren Server und derAnbindung der Geräte über WLAN oder UMTS analysiert die SySS GmbH die Sicherheitseinstel-lungen und bewertet diese unter Betrachtung des geforderten Schutzbedarfes. Ferner führt dieSySS GmbH eine Analyse des Datenverkehrs durch und versucht, die Verschlüsselung im Rahmeneiner Man-in-the-Middle-Attacke aufzubrechen.

Ausgangslage

Um Mobile Devices in das Unternehmensnetzwerk einzugliedern und die darauf gespeicher-ten Daten den Sicherheitsrichtlinien konform zu verwalten, wird ein sogenanntes Mobile DeviceManagement (MDM) eingesetzt. Da über diesen Dienst eine hohe Konzentration an unterneh-menskritischen Daten über das Internet erreichbar ist, stellen MDM-Server ein ertragreiches Zieldar.

Im Rahmen des Sicherheitstests prüft die SySS GmbH zunächst die Infrastruktur, welche zurAnbindung der Mobile Devices an das Unternehmensnetzwerk zuständig ist, auf Schwachstellenhin. Dabei wird, zum Beispiel, sowohl der Zugriff auf den E-Mail-Server analysiert als auchneben der Erfüllung der Sicherheitsanforderungen der Datenverkehr überwacht. Insbesondereder Registrierungsprozess und die Überprüfung, unter welchen Bedingungen das Mobile Deviceden Unternehmensrichtlinien entspricht, werden untersucht. Dabei geht die SySS GmbH vorallem der Frage nach, ob ein Gerät, dessen Sicherheit kompromittiert wurde, sich mit demUnternehmensnetzwerk verbinden kann und analysiert dafür die implementierte Jailbreak/Rooting-Erkennung. Abschließend schätzt sie das Sicherheitsniveau ein und schlägt Maßnahmen zurBehebung oder Abschwächung etwaiger Schwachstellen vor.

Durchführung

Der Penetrationstest gegen das Mobile Device Management kann aus dem SySS-Labor über dasInternet durchgeführt werden. Die SySS GmbH prüft den kompletten Lifecycle von der Provisio-nierung bis zur Stilllegung des Geräts. Dabei versucht sie, Schwachstellen in der Umsetzung derSicherheitsrichtlinien aufzuzeigen. Auf spezielle Sicherheitsbedürfnisse und Anforderungen des

Kunden sowie auf besondere Testszenarien kann an dieser Stelle eingegangen werden. Bestehtbeispielsweise die Anforderung, dass die Mobile Devices ausschließlich in einem klar definiertenZustand betrieben werden dürfen, versucht die SySS GmbH, diesen Zustand zu kompromittieren.

Im Rahmen von Data-Loss-Szenarien wird untersucht, durch welche Schnittstellen Informationendas Unternehmen verlassen können. Hierbei betrachtet die SySS GmbH die Frage, welche Vorkeh-rungen getroffen werden, damit ein Mitarbeiter nicht durch Nachlässigkeit Unternehmensdatenauf ein anderes, unsicheres Gerät kopieren kann. Falls eine Container-Lösung entsprechendeExport-Funktionen anbietet oder das Backup sich auf einem privaten Computer durchführenlässt, werden diese Schwachstellen aufgezeigt.

Für einen Test der mobilen Infrastruktur müssen je nach Testszenario folgende Anforderungenerfüllt werden:

• Freigabe, den über das Internet erreichbaren Mobile-Device-Management-Server zu prüfen

• Einsicht in die Profile des Mobile Device Managements

• Die Möglichkeit, Testgeräte selbst einzurichten

• Bereitstellung der zu testenden MDM-App, falls diese nicht über den App-Store bezogenwerden kann

Ansprechpartner

Der Test der mobilen Infrastruktur hat zahlreiche Schnittpunkte mit anderen Bereichen. Der fürdie Absicherung des über des Internet erreichbaren Management-Servers sollte ebenso wie derAnsprechpartner für das lokale Netzwerk und WLAN einbezogen werden. Sobald auch privateGeräte (Stichwort: Bring Your Own Device (BYOD)) involviert sind, sollten die Prozesse mit demBetriebsrat abgestimmt werden. Da bei der Prüfung kurzzeitige Verfügbarkeitsprobleme nichtausgeschlossen werden können, empfiehlt die SySS GmbH, alle Mobile-Device-Nutzer – auch zurSchaffung von Security Awareness – zu informieren.

Die folgenden aufgezählten Schwachstellen beschreiben exemplarische Verwundbarkeiten, die beiSicherheitstests innerhalb dieses Moduls auftreten können.

• Man-in-the-Middle-Angriff auf SSL-gesicherte Verbindung: Obwohl die Kommunikationzwischen dem mobilen Endgerät und MDM-Server verschlüsselt erfolgt, weist die Applika-tion jedoch eine Schwachstelle in der Überprüfung der Authentizität des Server-Zertifikatsauf. Bei nicht ordnungsgemäßer Implementierung kann ein Angreifer in geeigneter Positionden Datenverkehr abhören und modifizieren.

• Automatisierte Angriffe: Der über das Internet erreichbare Mobile-Device-Management-Server ist nicht hinreichend gegen automatisierte Angriffe geschützt. Ein Passwort-Rate-Angriff kann bei schwachen Passwörtern zum Erfolg führen.

• Jailbreak-Erkennung kann umgangen werden: Die zu testende Mobile-Device-Management-Lösung verfügt über eine Jailbreak-Erkennung, welche jedoch von einem Angreifer umgangenwerden kann. Ein von dem Mobile Device Management als sicher eingestuftes Gerät kann somitZugriff auf das Unternehmensnetzwerk erlangen. Jailbreaks sind sehr attraktiv für Nutzer, dasie ihnen enorme Vorteile bezüglich ihrer Mobil Devices bieten und sie somit manche Hürdenbei der Gerätenutzung umschiffen können. Ein gravierender Nachteil jedoch ist, dass derJailbreak verfällt, wenn das Gerät aktualisert wird. Somit hüten sich Nutzer, ihrem Gerätnotwendige Patches und Aktualisierungen einzuspielen, was wiederum die Ausnutzungvon Schwachstellen im Betriebssystem begünstigt.

• Sicherheitseinstellungen: Wenn Sicherheitseinstellungen nicht dem geforderten Schutzbe-darf des Kunden entspricht, kann es dazu kommen, dass ein Mitarbeiter geschäftliche undprivate Daten mischt und sowohl Kunde als auch Mitarbeiter nur geringe Vorkehrungen imHinblick auf Data Loss Prevention unternehmen.

2.8 INDIVIDUAL: Individuelles Anliegen

Sollte Ihr Anliegen nicht von den vorgestellten Modulen abgedeckt werden, zögern Sie nicht, unsanzurufen und es uns im Detail darzulegen. Wir werden in fast allen Fällen gemeinsam eine Lö-sung finden, da wir über langjährige Erfahrung und Expertise in nahezu allen Beratungsbereichender IT-Security verfügen.

2.8.1 Pivot - Kompromittierte Demilitarized Zone (DMZ)

ZusammenfassungDieses Modul geht von folgendem Szenario aus: Einem Angreifer gelingt es, mindestens einSystem in der demilitarisierten Zone (Demilitarized Zone; DMZ) – zum Beispiel einen Webserver –zu übernehmen. Die SySS GmbH wird beispielsweise durch Ausnutzung von Vertrauensstellungenoder weiteren Schwachstellen versuchen, weiter in die DMZ oder die internen Netzsegmenteeinzudringen.

Ausgangslage

Häufig besteht das Ziel von Angreifern darin, durch Ausnutzung von Schwachstellen wie SQL-Injection Informationen aus an Webapplikationen gekoppelten Datenbankmanagementsystemen zukopieren. Hierbei interessieren sich die Angreifer in vielen Fällen für Daten wie Passwörter, E-Mail-Adressen oder in der Datenbank gespeicherte Bezahlinformationen, um diese gewinnbringend zuverkaufen.

Verfolgen Angreifer jedoch die Absicht, gezielt einem bestimmten Unternehmen Schaden zuzu-fügen, so nutzen sie derartige Schwachstellen lediglich als Einstiegspunkt für weiterführendeAngriffsaktivitäten und die betroffenen Server als sogenannte Pivot-Systeme. Ihre eigentlicheMotivation ist in der Regel darin begründet, in das interne Unternehmensnetz einzudringen, umdie kritischen Daten des Unternehmens, beispielsweise geistiges Eigentum (Intellectual Property),zu veruntreuen. Im schlimmsten Fall ist ein solcher Angriff Teil eines Advanced Persistent Threat,

bei dem weitere Angriffstechniken wie Social Engineering oder Phishing-Methoden zum Einsatzkommen.

Im Rahmen dieses Moduls wird die SySS GmbH analysieren, welche Möglichkeiten sich einemAngreifer ergeben, der durch einen erfolgreichen Angriff einen Server in der DMZ kompromittie-ren konnte. Dieses System wird anschließend als Pivot genutzt, um weitergehende Angriffe derSySS GmbH darüber weiterzuleiten. Hierdurch können unter anderem die Vertrauensstellungenzwischen diesem und weiteren Servern ausgenutzt werden, um Angriffe gegen Systeme durch-zuführen, die nicht direkt aus dem Internet erreichbar sind. Ziel ist es, tiefer in die DMZ oderinternen Netzbereiche einzudringen.

Die SySS GmbH wird Empfehlungen aussprechen, durch deren Berücksichtigung das Ausmaßeines solchen Angriffs minimiert werden kann.

Durchführung

Da sich vor einem Projekt nicht abschätzen lässt, ob es der SySS GmbH beispielsweise imRahmen einer Webapplikationsanalyse aus eigener Kraft gelingen wird, in die DMZ des Kundeneinzudringen, wird der SySS GmbH in der Regel der Zugang zu einem Server in der DMZeingerichtet. Dies macht das Modul PIVOT zudem unabhängig von anderen Testmodulen. DerAblauf entspricht grob dem folgenden Muster:

• Hochladen der erforderlichen Werkzeuge (z. B. einen Proxy-/VPN-fähigen Payload) auf dasPivot-System

• Analyse des Pivot-Systems (z. B. Berechtigungen, lokale Credentials, Netzwerk-Schnittstellen,offene Verbindungen usw.)

• Pivoting (häufig auch Island Hopping genannt):– Prüfung der Erreichbarkeit weiterer Systeme innerhalb der DMZ sowie in internen

Netzbereichen– In enger Absprache mit dem Kunden: Angriffe gegen die identifizierten Systeme– Analyse weiterer kompromittierter Systeme

Zusätzlich können bei Bedarf auch die folgenden Prüfungen stattfinden:

• Gezielter Versuch, bestimmte interne Systeme anzugreifen (z. B. Datei- oder Mail-Server)• Durchlässigkeitsprüfung für dedizierte Netzbereiche (technisches Firewall-Regel-Review)

Für den Test muss der SySS GmbH auf jeden Fall ein Zugang zu einem System in der DMZeingerichtet werden. Üblicherweise handelt es sich bei diesem System um einen Web- oderApplikationsserver. Auch Datenbankserver, die häufig in separaten demilitarisierten Zonen un-tergebracht sind, können hierzu herangezogen werden. Um den produktiven Betrieb nicht zubeeinträchtigen, wird idealerweise ein technisch identischer Klon eines solchen Systems verwen-det. Wichtig ist, dass das System eine zur Produktivinstanz möglichst identische Konfigurationaufweist. Dadurch stehen der SySS GmbH sämtliche Angriffsmöglichkeiten bereit, die auch einemrealen Angreifer zur Verfügung stehen könnten.

Der Zugang wird idealerweise per SSH eingerichtet. Der SySS GmbH sollten die gleichen Be-rechtigungen eingeräumt werden, über die beispielsweise auch das Dienstkonto eines Web- oderApplikationsservers verfügt. Der Hintergrund hierzu ist, dass ein Angreifer sehr wahrscheinlichmit diesen Rechten ausgestattet ist, wenn er erfolgreich eine Schwachstelle in einer Webapplikationausnutzen konnte.

Alternativ kann auch ein spezieller VPN-Zugang (End-to-End) eingerichtet oder auf Protokolle wieRDP oder VNC zurückgegriffen werden. In jedem Fall sollte der temporär eingerichtete Zugangunbedingt so konfiguriert werden, dass er ausschließlich von den IP-Adressen der SySS GmbHausgenutzt werden kann. Der Kunde kann die SySS GmbH zudem durch die Benennung von füreinen Angreifer interessanten, internen Netzbereichen unterstützen, die im Zuge des Projektsangegriffen werden sollen.

Ansprechpartner

In den vorangegangenen Modulbeschreibungen wurden bereits einige Gründe genannt, weshalb(technischen) Ansprechpartner sowie deren Erreichbarkeit während des Testzeitraums sehr wichtigist. Diese gelten insbesondere auch für das Modul PIVOT. Ansprechpartner können unteranderem:

• Eventuelle Rückfragen während des Tests beantworten, die beispielsweise zur Verifizierungvon Sicherheitsschwächen dienen.

• Über mögliche Probleme wie eine eingeschränkte oder unterbrochene Erreichbarkeit desPivot-Systems oder anderer Systeme informiert werden und diese folglich zeitnah beheben.

Besonders der zweitgenannte Punkt – eine durchgehende, ununterbrochene Erreichbarkeit desPivot-Systems – ist im Rahmen dieses Moduls von äußerster Wichtigkeit, da sämtliche Tests überdieses System hinweg erfolgen.

2.8.2 Sicherheit von Anwendungen und Desktop-Systemen über Citrix AccessGateway

Ziel dieses Tests ist die Überprüfung der Sicherheit von Anwendungen und Desktop-Systemen, dieper Citrix Access Gateway (CAG) einem Anwender zugänglich gemacht werden. Hierbei wirdder Versuch unternommen, Nutzerrichtlinien zu umgehen, beziehungsweise aus dem Kontext derAnwendungen auszubrechen und eine Rechteeskalation zu forcieren. Sofern gewünscht, wirddie SySS GmbH versuchen, weitere von diesem System aus erreichbaren Netzwerkelemente zukompromittieren.

Durchführung

Je nach anzutreffender Anwendung oder vorgefundenem Desktop-System wird die SySS GmbHversuchen, über Systemdialoge, Tastaturkürzel oder falls möglich, über selbst geschriebene Pro-gramme, Zugriff auf eine Kommandozeile zu erhalten. Falls dies gelingt, werden in der RegelWörterbuch-basierte Rate-Angriffe auf das lokale Administratorkonto durchgeführt. Sofern perNutzerrichtlinie keine Sperrung von Domänennutzern vorgesehen ist, werden auch Domänenkon-ten mit einem automatisierten Passwort-Rate-Angriff attackiert. Werden auf dem lokalen SystemAdministratorrechte beziehungsweise Systemrechte erlangt, so wird unter anderem versucht,

Zugriff auf weitere im Netzwerk erreichbare Systeme zu erhalten. Während der Testphase ist esdurchaus üblich, dass die SySS GmbH prüft, ob es möglich ist, einen weiteren Kommunikations-kanal (Reverse-Shell) zu einem Server der SySS GmbH aufzubauen.

Voraussetzung

Vor Testbeginn wird die SySS GmbH im Rahmen des Kickoff-Gesprächs mit dem Kunden dasgewünschte Angriffsszenario beziehungsweise den Scope besprechen sowie Zugangsdaten fürdas CAG austauschen.

2.8.3 Produkt-/Labortests

Dieser Test dient für Untersuchungen, deren Tiefe über die Prüfung der Manipulierbarkeit einesReferenz-(PC-)Arbeitsplatzes im Rahmen des Moduls LANWAN hinausgehen soll. Testge-genstand sind sowohl multifunktionale Client- und Serversysteme als auch Systeme für einenspeziellen Aufgabenbereich (Automaten, Steuerungs- oder Kiosksysteme, tragbare Geräte, wiebeispielsweise Handys oder Smartphones, usw.). Die Testperspektive ist die einer Person, diephysikalischen Zugang zu dem System hat. Der Testumfang muss im Vorfeld definiert werden.Ein typisches Szenario ist die Bewertung des Risikos, welches sich aus einem Diebstahl desSystems oder einem Einbruch an seinem Aufbewahrungsort ergibt. Ein anderes wiederum istdie Bewertung des Risikos, welches von einem Missbrauch durch einen regulären (böswilligen)Nutzer des Systems ausgeht.

Durchführung

Diese ist völlig von dem zu testenden Produkt abhängig und wird daher im Kickoff besprochen.Je nach Komplexität und Art des zu testenden Produktes ist eine Zeiteinschätzung sehr schwierig.Generell wird daher während des Tests der Schwerpunkt darauf gelegt, hohe Risikopotentiale zuidentifizieren.

Aktive Tests werden während eines Produkttests nur an der Teststellung selbst durchgeführt.Ein Test wird nicht ohne Rücksprache und konkreten Auftrag auf andere Systeme des Kundenausgeweitet. Sollen abhängige Systeme getestet werden, so ist dies auf Wunsch im Rahmen despassenden Moduls (INTERNET, LANWAN, WLAN, WEBAPP) möglich.

Schwerpunkt ist sowohl die Suche nach Sicherheitsproblemen, die ausgenutzt werden können,ohne dabei bleibenden Schaden anzurichten (und die so unentdeckt bleiben) als auch solche, beidenen auf Kundenwunsch hin ein entstehender Schaden in Kauf genommen werden kann (Dieb-stahlszenario). Das Vorgehen wird im Vorfeld abgesprochen und sollte dem Szenario angepasstwerden. Bei einem Diebstahl beispielsweise ist nicht davon auszugehen, dass ein Garantiesiegelrespektiert wird.

Um einen solchen Test durchzuführen, müssen vor allem logistische Voraussetzungen erfülltwerden. So muss entweder der Transport der Teststellung oder der Zugang zu ihr organisiert

werden und wie bei anderen Tests auch ein Ansprechpartner für Rückfragen zur Verfügungstehen (ein Ansprechpartner sollte auch mit der Bedienung der Teststellung selbst vertraut sein).

Wenn es sich bei der Teststellung nicht um ein völlig autonomes System handelt, das getrenntvon anderen Systemen getestet werden kann, dann muss während des Kickoff-Gesprächs defi-niert werden, welche Tests an abhängigen Systemen durchgeführt werden können, und welcheAnsprechpartner in diesem Fall für diese zur Verfügung stehen.

Bei dem Kickoff sollte das Betriebssystem und die Hardwareplattform mitgeteilt werden. Zudemwird besprochen, ob der Testschwerpunkt auf die Kommunikation des Systems zu legen ist,inwieweit Software oder Hardware nachhaltig manipuliert werden kann. Ferner werden weiteredas System betreffende Details betrachtet.

Tipps von Sebastian SchreiberSchätzen Sie den Zeitbedarf für einen Produkttest sehr großzügig ein!

Prüfen Sie, mit welchen Systemen Ihr Produkt kommuniziert. In der Regel ist ein vollständigerTest dieser Systeme sinnvoll, wenn es sich ohnehin um eine organisatorische und technischeEinheit handelt. Wählen Sie anschließend das passende Modul für den Test.

2.8.4 Prüfung organisatorischer Vorgaben

Ausgangslage

IT-Sicherheit kann nur bei Betrachtung als Prozess2, nicht jedoch durch rein punktuelle Maßnah-men gewährleistet werden. Daher bietet die SySS GmbH Prüfungen der organisatorischen Vorga-ben an, welche die IT-Sicherheit definieren. Dies sind Security-Policies, Sicherheits-Handbücheraber auch Regelsets innerhalb der IT-Infrastruktur. Bei REVIEWs wird das zu prüfende Materialunseren Consultants zur Verfügung gestellt, welche sich anschließend damit vertraut machenund sowohl Verbesserungen als auch Änderungen empfehlen. Auf Wunsch können REVIEWsdurch Gespräche oder Workshops abgeschlossen oder flankiert werden. Dieses Modul deckt dienicht-technischen Untersuchungen im Rahmen von Sicherheitstests ab, ist jedoch nicht eigen-ständig. Um den Status der tatsächlichen Umsetzung von Vorgaben bzw. einer Security Policy zukontrollieren, empfehlen wir, zusätzlich das passende Testmodul zu wählen.

Voraussetzungen

Die SySS GmbH benötigt zur Durchführung eines Reviews jeweils aktuelle Versionen des zuprüfenden Materials. Ereignisse aller Art können schnell dazu führen, dass die in beliebigenVorgaben beschriebene Situation mit der realen nicht mehr übereinstimmt – Hinweise daraufsind nur von Mitarbeitern des Kunden erhältlich. Daher ist auch dieses Modul nicht ohneeinen Ansprechpartner des Kunden durchführbar, der im Rahmen eines Interviews Rückfragenbeantworten oder den Kontakt zu den jeweils Zuständigen vermitteln kann.

2 http://www.schneier.com/crypto-gram-0005.html

2.8.5 Simulierter Phishing-Angriff

ZusammenfassungIn der Presse ist immer wieder von erfolgreichen Einbrüchen in Unternehmen zu lesen. In einigenFällen geschieht dies über eine Ausnutzung von konkreten Schwachstellen in Systemen oderApplikationen. Oftmals ist jedoch auch eine simple E-Mail der Auslöser einer Kompromittie-rung. Immer häufiger versuchen Angreifer durch den Versand individualisierter, mit Schadcodeversehener E-Mails an ausgesuchte Opfer, Fuß in einem Unternehmensnetzwerk zu fassen. ImRahmen dieses Moduls führt die SySS GmbH im Auftrag des Kunden einen solchen zielgerichte-ten Phishing-Angriff durch und liefert als Ergebnis eine anonymisierte, statistische Auswertungdes Erfolgs.

Ausgangslage

Phishing ist kein neues Phänomen. Jeder Nutzer wird fast täglich mit dieser Angriffsform kon-frontiert. Doch während die üblichen „Rechnungs-E-Mails“ eher breitgefächert sind und keinenbestimmten Adressaten, sondern „die Masse“ erreichen sollen, werden im Rahmen von gezieltenPhishing-Angriffen auf ein bestimmtes Unternehmen individuell zugeschnittene E-Mails an ausge-wählte Empfänger versandt. Diese werden für verschiedene Mitarbeiter täuschend echt verfasst,um die Wahrscheinlichkeit eines erfolgreichen Angriffs zu erhöhen. In diesem Rahmen wird vonSpear Phishing oder Whaling gesprochen, wenn sich die Adressaten insebesondere aus den „dickenFischen“ des Unternehmens zusammensetzen.

Inhalt solcher gezielten Phishing-Mails sind oftmals mit Schadcode versehene Anhänge – bei-spielsweise vermeintliche Rechnungen – oder Links zu Webseiten, auf denen der Empfängerzur Eingabe seiner Zugangsdaten verleitet wird. Das Ziel der Angreifer besteht in der Regeldarin, einzelne Benutzerkonten oder gar Systeme innerhalb des Unternehmens unter ihre Hoheitzu bekommen, um von dort aus zum Beispiel schützenswertes, geistiges Eigentum der Firmazu kopieren und sich dadurch einen Wettbewerbsvorteil zu verschaffen. Industriespionage undAusspähaktionen sind ebenfalls kein neues Phänomen. Durch die aufgedeckte NSA-Spähaffäresind sie Mitte des Jahres 2013 jedoch wieder mehr in das öffentliche Bewusstsein gerückt.

Zielsetzungen des Tests

Im Rahmen dieses Moduls wird die SySS GmbH einen solchen Phishing-Angriff gegen dasbeauftragende Unternehmen durchführen. An dieser Stelle ist es besonders wichtig zu betonen,dass hierbei auf keinen Fall das Fehlverhalten einzelner Individuen aufgedeckt werden soll.Vielmehr wird die SySS GmbH den Angriff auf eine möglichst anonymisierte Weise durchführenund als Ergebnis eine quantitative, statistische Auswertung des Angriffserfolgs liefern (sieheAbbildung 2.1). Das Ergebnis kann von dem Kunden beispielsweise als Sensibilisierungsverstärkerin Security Awareness-Veranstaltungen verwendet werden.

Keine Reaktion37%

Link geklickt

Link geklickt und Zugangsdaten eingegeben

Abbildung 2.1: Beispielhaftes Ergebnis eines Phishing-Angriffs

Durchführung

Der Ablauf dieses Moduls entspricht grob dem folgenden Muster:

• Der Kunde stellt der SySS GmbH eine gewisse Anzahl an E-Mail-Adressen zur Verfügung(z. B. 200 Empfänger).

• Die SySS GmbH bereitet den Phishing-Angriff vor. Hierzu werden Informationen über dasUnternehmen gesammelt und der Inhalt der E-Mail gestaltet sowie eventuelle Phishing-Seitenvorbereitet.

• Die SySS GmbH wird die E-Mail an eine zufällige Unterauswahl der bereitgestellten E-Mail-Adressen versenden.

• Nach einer gewissen Frist (in der Regel nach wenigen Tagen) wird die SySS GmbH das Er-gebnis auswerten und dem Kunden in Form einer anonymen, quantitativen Dokumentationzur Verfügung stellen.

Die Vorbereitungsaufgaben des Kunden bei diesem Modul sind sehr überschaubar. Der SySSGmbH muss lediglich die Liste der E-Mail-Empfänger (siehe „Durchführung“) zur Verfügunggestellt werden. Gerne kann der Kunde der SySS GmbH auch Informationen bereitstellen, die dieGlaubwürdigkeit der Phishing-E-Mail erhöhen.

Die SySS GmbH rät dazu, den Phishing-Angriff vorab mit dem Ansprechpartner des Kundendurchzuspielen. Hierdurch kann zum Beispiel verhindert werden, dass der Angriff aufgrund vonsich möglicherweise im Einsatz befindenden Filtermechanismen scheitert und die E-Mails ihreEmpfänger erst gar nicht erreichen. Derartige Eventualitäten sollten vor der Durchführung desModuls auf jeden Fall gemeinsam besprochen werden.

Der Kunde sollte sich zudem darauf vorbereiten, dass der Phishing-Angriff im Unternehmenauffällt und Rückfragen gestellt werden. Umso wichtiger ist es zum einen, den Angriff zeitlich

stark einzuschränken und zum anderen unmittelbar nach Beendigung des Angriffs für Aufklärungund Entwarnung zu sorgen!

Ansprechpartner

Eine Erreichbarkeit des Ansprechpartners während der Moduldurchführung ist, wie auch beiden anderen Modulen, obligatorisch. Beispielsweise könnten beim Versand der Phishing-E-Mailsunvorhersehbare Hürden auftauchen. Zudem sollte der Ansprechpartner auch für die Empfängerstets für Rückfragen zur Verfügung stehen.

2.9 Grundlagen des Sicherheitstests

Ein Sicherheitstest wird durchgeführt, um Sicherheitsschwächen verschiedenster Art erkennenund anschließend beseitigen zu können.

2.9.1 Grenzen von Sicherheitstests

Ein Sicherheitstest stellt eine Analyse des Ist-Zustandes dar. Risiken, die sich durch möglicheKonfigurationsänderungen oder neue Erkenntnisse in der Zukunft ergeben könnten, lassensich nur schwer erkennen – derartige Überlegungen haben immer spekulativen Charakter. UmSchlagkraft zu besitzen, müssen Sicherheitstests daher regelmäßig durchgeführt werden. Zudemsind die Sicherheitslücken, die entdeckt werden können, von der Testperspektive abhängig. Beieinem Test nach dem Modul INTERNET werden zum Beispiel lokale schwache Passwörter nichtentdeckt, wenn es gar keine Möglichkeit gibt, sich an dem zu überprüfenden System vom Internetaus anzumelden.

Ein weiteres Problem ist Budgetknappheit: Werden große Netze oder komplexe Webapplikationenin einem kurzen Zeitraum geprüft, besteht die Gefahr, dass Sicherheitslücken schlichtweg ausZeitmangel nicht identifiziert werden können. Ein potentieller Angreifer, der sich ausreichend Zeitfür eine tiefgehende Untersuchung nimmt, kann diese Sicherheitslücken aufdecken und ausnutzen.Generell legt ein Sicherheitstest den Schwerpunkt auf die Identifikation von Schwachstellen, diezum Testzeitpunkt ein hohes, konkretes Risiko darstellen.

2.9.2 Abgrenzung von Sicherheitstests zu anderen Prüfungen

Im Vergleich zu IT-Grundschutz-Audits oder Zertifizierungen nach ISO 27001 ist ein Sicherheitstestvor allem konkret – er schafft überprüfbare Fakten und benennt direkte Bedrohungen für dieIT-Sicherheit.

Sicherheitslücken können auch nachgewiesen werden, wenn BSI-zertifizierte Software einge-setzt wird und ein ISO 27001-Zertifikat vorliegt. Daher sind autonome Sicherheitstests, die vonSpezialisten durchgeführt werden, Sicherheitsprüfungen im Rahmen entsprechender Auditsvorzuziehen.

Sie stehen dabei aber nicht in Konkurrenz zu derartigen Maßnahmen, sondern eignen sich idealzur Unterstützung – vor allem, da die Ergebnisse vergleichsweise zügig vorliegen und in einbestehendes Audit integriert werden können.

56 Whitepaper | Digitale Forensik & Incident Response

3 Digitale Forensik & Incident Response

IT-Sicherheitsvorfälle sind leider keine Seltenheit. Immer wieder kommt es zu Datenklau undBetriebsspionage, und wenn solche Fälle bekannt werden, ist es wichtig zu wissen, wie amschnellsten und effizientesten gehandelt werden kann. Sollten Sie betroffen sein, so unterstützt Siedie SySS GmbH bei der Aufklärung solcher Fälle und der Sicherung von gerichtsverwertbarenDaten in Ihrem Unternehmensnetzwerk. Ferner beraten wir Sie, wie Sie angesichts der gestiegenenBedrohungslage Ihre IT-Infrastrukur und sämtliche vertraulichen Daten in Ihrem Unternehmenbesser schützen können.

3.1 Digitale Forensik

Digitale Forensik bezeichnet die Erfassung und Analyse von digitalen Spuren auf IT-Systemen.Diese werden gerichtsverwertbar ausgewertet, um als Beweismittel dienen zu können. Sollteder Verdacht auf einen Missbrauchsfall vorliegen, leistet die SySS GmbH Hilfestellung bei allenerforderlichen Maßnahmen, die getroffen werden müssen, um ein Forensik-Projekt umzusetzen:

• Gerichtsverwertbare Auswertung von Datenträgern aller Art• Auswertung von Log-Dateien nach einem Angriff• Analyse von unerwünschter Netzwerkaktivität

Die SySS GmbH verfügt über ein umfangreich ausgestattetes Forensik-Labor und hält eine großeAnzahl an Soft- und Hardware vor, um eine möglichst effiziente Bearbeitung aller Fälle zuermöglichen.

3.2 Incident Response

Der Begriff Incident Response (IR) behandelt sowohl die Untersuchung von verdächtigen Aktivitätenin Zusammenhang mit IT-Systemen als auch IT-Sicherheitsvorfälle, wobei bezüglich der IT-Sicherheit meist Vorfälle größeren Ausmaßes gemeint sind, wie zum Beispiel:

• Malware breitet sich im Netzwerk aus• Auf einem internen Server werden Spuren eines Angriffs gefunden• Im Internet sind Geschäftsgeheimnisse veröffentlicht worden• Im Active Directory wurde ungewöhnliche Aktivität festgestellt

Um Sicherheitsvorfälle abzuwenden, baut das Incident Response Management auf die möglichsteffiziente Nutzung der vorhandenen personellen und technischen Ressourcen. Die steigendeQualität externer Angriffe auf Firmennetzwerke erfordert eine strukturierte Herangehensweisebei der Aufklärung und Wiederherstellung solcher Vorfälle. Unsere langjährige Erfahrung imErkennen und Bewerten von Sicherheitslücken bietet uns das notwendige Know-how, um Ihnenauch über die Analyse der Vorfälle hinaus zur Seite zu stehen.

Digitale Forensik & Incident Response | Whitepaper 57

Sollten Sie einen IT-Sicherheitsvorfall vermuten, so zögern Sie nicht, uns deswegen anzusprechen3.Wir garantieren Ihnen die Beantwortung Ihrer Anfrage innerhalb von 24 Stunden durch einentechnischen Berater.

Unsere IR-Dienstleistung umfasst unter anderem die folgenden Punkte:

• Aufklärung und Einschätzung von Angriffen auf Ihr Unternehmensnetzwerk• Hilfe bei elektronischer Industriespionage und Advanced Persistent Threats (APT)• Kompetente telefonische Beratung• Malware-Analyse• Individuelle Workshops und Schulungen zur Weiterbildung Ihrer IT-Sicherheitsmitarbeiter

Die Incident Responder der SySS GmbH sind aktive Mitglieder der internationalen ResponderCommunity und der Allianz für Cybersicherheit des BSI4 und der BITKOM. Sie bilden sich stetigfort und arbeiten konstant an der Weiterentwicklung von kreativen Problemlösungsstrategien imBereich der Forensik & Incident Response.

3 Am besten schreiben Sie an DFIR@syss.de oder entnehmen Sie unsere Incident-Response-Notfallnummer unsererHomepage www.syss.de

4 Bundesamt für Sicherheit in der Informationstechnik www.bsi.de

58 Whitepaper | Über die SySS GmbH

4 Über die SySS GmbH

4.1 Firmengeschichte

Die SySS GmbH wurde 1998 von Diplom-Informatiker Sebastian Schreiber gegründet, um hoch-wertige Sicherheitstests anzubieten. Gegenwärtig5 beschäftigt die SySS GmbH 70 Mitarbeiterinnenund Mitarbeiter, von denen sich 50 ausschließlich mit Sicherheitstests beschäftigen.

Kunden der SySS GmbH sind Unternehmen aller Branchen und Größen. Dazu zählen unteranderem Basler Versicherungen, Bosch, Bundeswehr, CreditPlus Bank, Daimler, Deutsche

Bank, Deutsche Flugsicherung, Festo, Hewlett-Packard, Innenministerium/L Niedersach-sen, SAP, Schaeffler, Schufa, T-Systems sowie die Union Investment. Weitere Referenzkundenfinden Sie auf der Homepage der SySS GmbH.

Die SySS GmbH hält Fachvorträge auf nationalen und internationalen Kongressen, bisher inBelgrad, Berlin, Bratislava, Bukarest, Budapest, Dublin, Helsinki, Kiew, Las Vegas, Lissabon,Ljubljana, London, Moskau, München, Paris, Prag, Riga, Stockholm, Wien, Zagreb.

Mitarbeiter der SySS GmbH sind immer wieder als Experten in diversen Printmedien wie Der

Spiegel, Die Zeit, Financial Times Deutschland, Stuttgarter Zeitung, Süddeutsche Zei-tung, etc. und Funk- und Online-Medien wie ARD, CHIP TV, Hessischer Rundfunk, Pro7, RTL,Südwestrundfunk, SternTV und ZDF präsent.

4.2 Grundlegende Ethik für Penetrationstester

Basierend auf schon existierenden Kodizes und über Jahre gesammelten Erfahrungswerten, hatdie SySS GmbH den ersten Vorstoß unternommen, eine grundlegende Ethik für Penetrationstesterzu erstellen. Diese Ethik wurde in der Ausgabe 04/2009 in der IT-Zeitschrift Datenschutz und Da-tensicherheit (DuD) zum ersten Mal veröffentlicht und spiegelt die Einstellung und die Grundlagedes Arbeitens bei der SySS GmbH wider. Aufgrund dieser Ethik gestalten wir unsere Arbeit:

Unabhängigkeit: Penetrationstests durchführende Firmen testen nur in solchen Unternehmen, indenen sie weder bei der Konzipierung der IT-Umgebung noch der Einrichtung von Sicher-heitsmaßnahmen beteiligt gewesen sind und an die sie auch keine eigene Software verkaufthaben oder verkaufen wollen. Nur so kann sichergestellt werden, dass die Ergebnisse desTests objektiv sind.

Vertraulichkeit: Sowohl die Identität der beauftragenden Firma als auch jegliche Einblicke ininterne Netzwerke, Strukturen sowie in jegliche Daten, ebenso auch die, die dem Penetrati-onstester zur Verfügung gestellt werden, sind absolut vertraulich zu behandeln.

Provisionsverbot: Die Annahme von Provisionen oder vergleichbaren Vorteilen ist untersagt.Vorsicht: Der Kunde ist über mögliche Risiken in Kenntnis zu setzen, die bei den Prüfungen

erstehen können.

5 Stand 1. März 2015

Über die SySS GmbH | Whitepaper 59

Professionalität und Qualitätsmanagement: Die Arbeit hat professionell zu erfolgen und isteinem Qualitätsmanagement zu unterziehen. Dabei leistet der Penetrationstester seine Arbeitnach bestem handwerklichem Wissen und ethischem Gewissen.

Verbindlichkeit: Vertraglich zugesicherte und in Beratungsgesprächen mündlich getroffene Zu-sagen sind von den Mitarbeitern der Penetrationstests durchführenden Firma verbindlicheinzuhalten.

Objektivität, Neutralität und Transparenz: Schlussfolgerungen müssen objektiv sein und sindnachvollziehbar darzustellen.

Interessenskonflikte: Interessenskonflikte zwischen Penetrationstestern und Kunden sind zuvermeiden und gegebenenfalls anzuzeigen und auszuräumen.

Striktes Legalitätsprinzip: Die Gesetze der von Penetrationstests betroffenen Länder sind strikteinzuhalten, auch wenn Teilergebnisse eines Penetrationstests selbst einen Interessenkon-flikt mit der vorgefundenen Gesetzgebung darstellen könnten. So kann die Aufdeckungvon Schwachstellen in bestimmten Fällen Verstöße gegen bestehendes Recht begünstigen.Penetrationstester sind daher verpflichtet, sich mit der jeweiligen Gesetzeslage vertrautzu machen und sorgfältig darauf zu achten, dass ihre Arbeit innerhalb der vorgegebenenGesetzesgrenzen abläuft.

Respekt vor Menschen: Social Engineering-Attacken sind Angriffe gegen das Verhalten vonMenschen – diese werden, sofern sie überhaupt realisiert werden, ausschließlich angekündigtdurchgeführt.

Korrektes Zitieren: Wird fremdes Wissen bei der Arbeit herangezogen und verwertet, so sinddie Quellen/Urheber korrekt auszuweisen.

60 Whitepaper | Über die SySS GmbH

4.3 Veröffentlichungen der SySS GmbH (Auswahl)

Die SySS GmbH veröffentlicht regelmäßig Artikel in Fachzeitschriften, auf Online Plattformenoder im Rahmen von Kongressen.

Hier finden Sie eine Auswahl:

Schreiber, Sebastian: Komplexität bildet das Hauptproblem. In: isreport 10, 2012.

Schreiber, Sebastian: Wir bemerken eine zunehmende Professionalisierung der Angreifer. In: Bankmaga-zin 10, 2012.

Schreiber, Sebastian: Windows 8 – Der richtige Weg. In: CHIP 8, 2012.

Heitmann, Kirsten/Schreiber, Sebastian: Sicherheit bei Web-Shops. http://www.ecommerce-vision.de, 16. Mai, 2012.

Deeg, Matthias: Deaktivierung von Endpoint-Protection-Software auf nicht autorisierte Weise.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/Fallstudie_-_Deaktivierung_von_Endpoint_Protection_Software_auf_nicht_autorisierte_Weise.pdf,Juni 2012.

Deeg, Matthias: SySS knackt einen weiteren USB-Stick.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/SySS_knackt_einen_weiteren_USB-Stick.pdf, Februar 2011.

Deeg, Matthias: Rechteausweitung mittels Antivirensoftware.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/Rechteauswe

itung_mittels_Antivirensoftware.pdf, Januar 2011.

Borrmann, Micha: Kurze Sicherheitsanalyse von OWOK light.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/owoklight-

2011-01.pdf, Januar 2011.

Bott, Christoph/Schreiber, Sebastian: Bedroht „Hole 196“ die WLAN-Security? In: VAF Report 3,2010.

Deeg, Matthias/Eichelmann, Christian: Angriff auf Online-Banking-Applikation.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/Angriffe_au

f_Internetbanking_MDR_22_03_2010.pdf, März 2010.

Eichelmann, Christian: SySS späht Daten auf iPhones aus.https://www.syss.de/fileadmin/ressources/040_veroeffentlichungen/dokumente/Datensicher

heit_iphone.pdf, Februar 2010.

Schreiber, Sebastian: Rechtliche Aspekte von Penetrationstests. In: Wirtschaftsinformatik und Mana-gement 1 (2010).

Schreiber, Sebastian: Totgesagte leben länger. In: KES 4, 2009.

Schreiber, Sebastian: Vorschlag zum Entwurf einer Berufsethik für Penetrationstester. In DuD. Daten-schutz und Datensicherheit 4, 2009.

Muncan, Michael/Schreiber, Sebastian: Interne Penetrationstests – Sicherheitstests im Firmennetz. In:DuD. Datenschutz und Datensicherheit 4, 2009.

Arbeiter, Stefan/Deeg, Matthias: Bunte Rechenknechte. In: C’t 6, 2009.

Über die SySS GmbH | Whitepaper 61

Borrmann, Micha/Bachfeld, Daniel: Zechpreller: Unsichere Bezahlungssyteme. In: C’t 6, 2008.

Heinrich, Katrin/Schreiber, Sebastian: Penetrationstests als Instrument der Qualitätssicherung. In: ITSicherheit und Datenschutz 6, 2007.

Bott, Christoph/Schreiber, Sebastian: Penetrationstests – Hackerangriffe als Kontrollinstrument. In:S&I 4, 2007.

Borrmann, Micha/Schreiber, Sebastian: Sicherheit von Webapplikationen aus Sicht eines Angreifers. In:DuD. Datenschutz und Datensicherheit 11, 2006.

Schreiber, Sebastian: Suchmachinen als Hackerwerkzeug. In: PC-Magazin 7, 2006.

Schreiber, Sebastian: Securitykosten am Beispiel von Penetrationstests. In: Praxis der Wirtschaftsinfor-matik 4, 2006.

Schreiber, Sebastian: Google Hacks – penetrante Suchmaschinen. In: KES 4, 2005.

Schreiber, Sebastian: Hackertools und Penetrationstests. In: HMD 236. Praxis der Wirtschaftsinforma-tik. Ausgabe v. 23. April, 2004.

Kroma, Pierre/Schreiber, Sebastian: Störfunk - D.o.S. gegen WLANs in: Heise Security, Ausgabe v.12. März, 2004

Borrmann, Micha/Schreiber, Sebastian: Wer zählt, gewinnt. In: C’t 23, 2003, S. 212.

Borrmann, Micha: Unentdeckt Ports scannen. In: Network Computing 10-11, 2003, S.46.

Schreiber, Sebastian: Ans Licht gebracht. In: Kommune21 6, 2003, S.34f.

Bei Interesse senden wir Ihnen gerne unsere Pressemappe zu, die Artikel von und über die SySSGmbH enthält.

SySS GmbHWohlboldstraße 872072 Tübingen

Tel.: +49 - (0)7071 - 407856-0Fax: +49 - (0)7071 - 407856-19

E-Mail: info@syss.dehttp://www.syss.de

Whitepaper (SySS GmbH)files.messe.de/abstracts/63759_whitepaper_syss_deutsch.pdf · 2015. 10....

Documents

Transcript of Whitepaper (SySS GmbH)files.messe.de/abstracts/63759_whitepaper_syss_deutsch.pdf · 2015. 10....

Vertikalmühlen- Entlastung der Getriebeexperten durch ...files.messe.de/abstracts/43464_MDA_Forum_Vortrag_Dr_Deckers_Siemens_AG.pdf · CMS-Architektur Vertikalmühlen-getriebe Zusammenfassung

Baez, John; Schreiber Urs - Higher Guage Theory I

Ellen Schreiber - Vampire Kisses 07 - Love Bites

51120577 David Servan Schreiber Anticancer

Andreas Schreiber · PDF fileApps für alle Plattformen entwickeln ! Plattformübergreifende App- Entwicklung mit Python und Kivy . Andreas Schreiber

Nico Schreiber*, Heike Theyßen*, Horst · PDF fileExperimentelle Kompetenz messen?! Nico Schreiber*, Heike Theyßen*, Horst Schecker + *Lehrstuhl für Didaktik der Physik, TU Dortmund,

HACKING & SECURITY 2021 - SySS · Hack1: Hacking Workshop 1 6 Hack2: Hacking Workshop 2 7 Hack3: Angriffe auf Windows-basierte Netzwerke 8 Hack4: Angriffe gegen VoIP-Infrastrukturen

Schwachstellen vor dem Hacker finden - SySS GmbH · PDF file24 ITea 2016 IT-SIcherheIT E nergieversorger werden immer häufiger Opfer von Hackerangriffen. Dabei stellt oft die nicht

David Servan-Schreiber - Szíveddel figyelj

Schreiber ProdKata 2.2009 - asm- · PDF fileQualität und Leistungsfähigkeit sind die Maximen, nach denen die Adolf Schreiber GmbH, Münsingen, kurz ASM, ihre Produkte entwickelt

Europeana regia Zwischenbericht aus einem EU-Projekt Dr. Wolfgang-Valentin Ikas Dr. Carolin Schreiber Dr. Wolfgang-Valentin IKAS · Dr. Carolin SCHREIBER.

2005-04-05 CIPPIC Paul Schreiber

Schreiber, Uwe - Black Soul

(Schreiber), Vogelwart

Flora Rheta Schreiber - Sybil

Singleton Schreiber McKenzie & Scott Trial Lawyers

01.Ppt Daniela Schreiber

Bernd Schreiber – Das Synthesizer-Handbuch

Servan Schreiber David - Anticancer.rtf

Norbert Schreiber - Uni Trier...Prof. Dr. Michael-Sebastian Honig, Dr. Magdalena Joos, Dr. Norbert Schreiber Das Forschungsprojekt wird finanziell gefördert durch das Bistum Trier,

Nico Schreiber, Heike Theyßen, Horst · PDF fileExperimentelle Kompetenz messen?! Nico Schreiber, Heike Theyßen, Horst Schecker + *Lehrstuhl für Didaktik der Physik, TU Dortmund,