Azubi Capture-The-Flag 2022

,

Im September fand jeweils vom 09.09 – 11.09 und vom 23.09 – 25.09 das Azubi-Boot-Camp 2022 statt, worin es darum geht, Auszubildende im IT-Bereich den Einstieg in die Berufs- und IT-Welt zu vereinfachen. Hierzu bietet das Azubi-Boot-Camp eine Vielzahl von interessanten und informativen Vorträgen und Workshops aus den Bereichen Kommunikation, Wissensmanagement, Datenschutz, Teamwork und IT-Sicherheit.

Zum Thema IT-Sicherheit durften wir nun bereits im Dritten Jahr in Folge einen Beitrag leisten und haben ein Hacking-Event in Form eines sogenannten Capture-The-Flag veranstaltet. Beim Capture-The-Flag geht es darum, Aufgaben in verschiedenen Kategorien zu lösen und die „Flag“ zu erlangen. Wir hatten zum einen die Herausforderung, passende Challenges zu entwerfen, die für ein breites Publikum mit unterschiedlichen Wissensständen angemessen ist und zum anderen, den Spaß an der Technik hervorzuheben bzw. auch zu fördern.

Es standen die Kategorien Infrastructure, Web und Forensics zur Verfügung, in denen es jeweils mehrere Challenges mit unterschiedlichen Schweregraden von Easy bis Nightmare gab, es war also für jeden etwas dabei. In der Kategorie Infrastructure ging es darum, Schwachstellen in Infrastrukturkomponenten, wie SSH oder SNMP zu finden. Im Bereich Web waren Schwachstellen rund um Web-Entwicklung zu finden, hierzu gehören bspw. die Analyse von JavaScript-Funktionen, der Umgang mit den Browser Developer Tools, oder das einfache Ausnutzen einer Command Injection-Schwachstelle. Zu guter Letzt durften die Auszubildenden grundlegende forensische Analysen durchführen, wie das Finden einer Zeichenkette in einem Bild, das Umgehen einer Passwortabfrage in einer Applikation, oder das Verständnis zu Magic Numbers.

Es war uns während der Veranstaltung besonders wichtig, auch aktiv Tipps zu geben und zu motivieren, wenn es doch vielleicht mal nicht weiter ging. Die Resonanz am Ende der Veranstaltung hat uns wieder gezeigt, dass es wichtig ist, junge Menschen für den Bereich IT-Sicherheit zu begeistern, versteckte Talente zu entdecken und zu fördern.

Wer sich gerne selber mal ausprobieren möchte, für den gibt es eine Vielzahl an Plattformen, die sich für den Einstieg eignen.

/von

Aus Angreifersicht! – Webinare zum Thema ‚Sicherheitsanalysen‘

Erfahren Sie anhand konkreter Beispiele aus der Praxis, wie Angreifer in Ihre IT-Infrastruktur eindringen und so Ihr Unternehmen schädigen – durch Datendiebstahl oder -verschlüsselung. Zudem zeigt Ihnen Jens Regel, wie Sie mit Sicherheitsanalysen von CRISEC das Bewusstsein für solche Bedrohungen in Ihrem Unternehmen steigern und so Angriffen aktiv vorbeugen.

Mitarbeitersensibilisierung durch Phishing-Kampagnen
28. Juli 14:00 – 15:00 Uhr

Phishing-Mails sind heutzutage eine der am häufigsten verwendeten Methoden, um Mitarbeiter in Unternehmen anzugreifen und anschließend Daten zu erbeuten oder zu manipulieren. Wir zeigen Ihnen die Vorgehensweise von realen Angreifern und wie Sie mit Phishing-Kampagnen das Sicherheitsbewusstsein Ihrer Mitarbeiter nachhaltig erhöhen können.

→ Direkt zum Webinar anmelden

Ransomware (Conti & Co.)
29. September 14:00 – 15:00 Uhr

Sie erfahren in diesem Webinar, wie Angreifer sich Zugriff auf Unternehmensnetzwerke verschaffen und wie die typische Vorgehensweise dieser Angreifer ist. Hierzu werden wir auch einen kleinen Ausflug ins ominöse Darknet durchführen.

→ Direkt zum Webinar anmelden

Die Top 5 Schwachstellen in Unternehmensnetzwerken
24. November 14:00 – 15:00 Uhr

Sie lernen in diesem Webinar die Top 5 der von uns identifizierten Schwachstellen in Unternehmensnetzwerken kennen und erfahren, welches Risiko diese für Ihre Unternehmensdaten bedeuten.

→ Direkt zum Webinar anmelden

 

 

© xkcd  [https://xkcd.com/1247/]

/von

Testmethodiken: Blackbox, Whitebox & Greybox

Während eines Erstgesprächs zu einem Penetrationstest ist es wichtig, die Informationsbasis gemeinsam mit dem Kunden zu definieren. Die Informationsbasis legt fest, welche Informationen wir im Vorfeld als unabhängiger Tester über die zu prüfenden Systeme vom Kunden erhalten. Man unterscheidet dabei im Allgemeinen zwischen den Methodiken Blackbox, Whitebox, und Greybox. Nachfolgend erläutern wir den Unterschied zwischen den einzelnen Methodiken.

Blackbox

Durch die Testmethodik Blackbox erhält der Pentester nur rudimentäre Informationen wie bspw. IP-Adressen oder Hostnamen der zu testenden Objekte. Er hat weder Dokumentationen noch Zugänge zum System. Hierbei wird ein Angriff eines externen Täters simuliert, der keinerlei Insiderwissen besitzt und sich alle notwendigen Informationen erst während des Tests erarbeiten muss.

Whitebox

Bei einem Whitebox-Test erhält der Pentester weitreichende Informationen über das zu testende Objekt. Dies kann bspw. der Sourcecode einer Applikation sein, entsprechend detaillierte Dokumentationen der Infrastruktur oder Accounts mit administrativen Berechtigungen. In dieser Methodik wird die Sicht eines potenziellen Innentäters oder Entwicklers simuliert. Der Whitebox-Test ist die umfangreichste und zeitintensivste Testmethodik, da durch die vorherige Offenlegung aller relevanten Informationen der Umfang der zu durchführenden Tests auf ein Maximum steigt.

Greybox

Der Greybox-Ansatz ist eine Kombination aus den beiden anderen Methoden. Der Pentester hat in diesem Fall bereits grundlegende Kenntnisse über die Infrastruktur oder Applikation. Ein gängiges Szenario wäre bspw. der Zugriff mit Benutzerrechten auf eine Webapplikation oder der Test von internen Netzwerkinfrastrukturen unter Verwendung von Topologieplänen und entsprechenden Dokumentationen der aktiven Netzwerkkomponenten.

Der Greybox-Ansatz ist die am häufigsten zum Einsatz kommende Methode und wird zudem von uns empfohlen. Der Vorteil hierbei besteht darin, dass gemeinsam mit dem Kunden definiert werden kann, auf welche Funktionalitäten einer Applikation oder eines Systems der Fokus festgelegt werden soll. Der Pentester kann sich gezielt auf die angegebenen Systeme konzentrieren und diese zielgerichtet analysieren. Im Blackbox-Ansatz muss erst durch umfangreiche Recherche Informationen über das Ziel gesammelt werden. Durch den Mehraufwand der Informationsbeschaffung bleibt weniger Zeit für die tiefergehenden Prüfungen, was ggf. zur Folge hat, dass wichtige Funktionen ungeprüft bleiben. Kontaktieren Sie uns gerne und wir finden gemeinsam mit Ihnen die passende Testmethodik für einen Penetrationstest.

/von

Apache Log4j – Lessons Learned?

“We build our computers the way we build our cities — over time, without a plan, on top of ruins.”

― Ellen Ullman

Das ist einer meiner Lieblingssprüche, wenn es um die Beschreibung des allgemeinen Sicherheitsniveaus unser aller IT-Systeme geht. Umso mehr trifft dieser Spruch auf das Apache Log4j Desaster zu, womit sich aktuell die halbe Welt beschäftigt und Admins panisch alles stehen und liegen lassen, um Systeme zu patchen. Nun ist es so, dass man für sich klar haben sollte, dass solche Schreckensszenarien in der Zukunft immer wieder und vor allem häufiger auftreten werden. Dies liegt hauptsächlich an der steigenden Komplexität von IT-Systemen und der Art und Weise, wie heutzutage Software entwickelt und Infrastrukturen gebaut werden, und zwar: over time, without a plan, on top of ruins.

Wenn wir uns „State of the Art“-Softwareprojekte anschauen, werden wir feststellen, dass dort mit Abhängigkeiten zu Third-Party Libraries nicht gekleckert wird. Ganz besonders schlimm ist dies bei Webapplikationen, da zieht man sich ganz schnell mal eine mittlere zweistellige Zahl an Dependencies in die Codebase, die von irgendwelchen Menschen mal entwickelt wurden und mehr oder weniger gepflegt sind. Da diese Third-Party Libraries meist Hobby bzw. semiprofessionelle Ansätze verfolgen, kann man als Nutzer nicht erwarten, dass der Informatiker, der nebenbei nach der Arbeit mal einen NodeJS Parser für Excel-Dateien gehackt hat, regelmäßig das Projekt und seinen Code pflegt, den Bugtracker im Blick hat und Pull Requests sichtet.

Wir sehen z.Zt. etliche Hersteller, die ihre komplexen Softwareprodukte auf Anfälligkeiten bzgl. der Log4j Schwachstelle prüfen. Alleine die Tatsache, dass man seine Codebase erst prüfen muss, um dann später festzustellen, ob die Library überhaupt im Einsatz ist oder in welcher Version diese mitgeliefert wird, sagt einiges über die Qualitätsprozesse der Hersteller aus.

Während Penetrationstests stellen wir diese Problematik leider regelmäßig fest, oft heißt es im Reporting: „Remote Code Execution durch veraltete und verwundbare Library X“ oder „Cross-Site Scripting durch veraltete und verwundbare Library Y“.

Was lernen wir nun daraus?

Schwachstellen entstehen nun mal, wenn Menschen Software entwickeln, das ist unvermeidlich und auch Ok. Wir benötigen aber allerdings für unsere IT-Systeme viel weniger Komplexität und mehr Klarheit darüber, wie diese tatsächlich funktionieren, dadurch ergibt sich einfacheres und schnelleres handeln, wenn es wirklich darauf ankommt.

Ein Kommentar von Jens Regel.

/von