Der Security-Adventskalender 2022. 24 Türchen: 24 Folgen

Lisa: Hallo und herzlich willkommen zum Türchen Nummer 25 des INNOQ Security Podcast Adventskalenders. Ihr fragt euch jetzt sicherlich alle: Warum Türchen 25? Wir sind im neuen Jahr. Wir wollen keinen Adventskalender mehr. Aber wir wurden nach der Lösung gefragt. Wie man unser Weihnachtsrätsel denn lösen könnte. Und das möchten wir euch gerne erklären. Hallo, hier ist übrigens Christoph: auch noch. Ich habe gar nicht gesagt, dass Christoph noch da ist.

Christoph: Hallo Lisa.

Lisa: Sorry, ich bin ganz vertrottelt schon. Und wir wollen euch gerne die Lösung sagen für das Rätsel. Aber uns ist aufgefallen, wir haben auch noch das Rätsel aus 2021 und nicht nur das aus 2022. Also nutzen wir diese Folge, um euch beide Rätsel zu erklären und wie ihr denn zur Lösung kommt. Für dieses Jahr gibt es keine Gewinnchancen, da die Gewinnerin schon benachrichtigt wurde. Und ich würde sagen, wir starten dann mal durch mit dem Rätsel für 2021, oder?

Christoph: Ja, das ist eine gute Idee.

Lisa: Sehr gut. Wir machen das jetzt so: Die Rätselhinweise waren jeweils immer im Gedicht versteckt. Folge 24 war ein Gedicht auch schon im Jahr 2021. Ich lese euch die passende Stelle aus dem Gedicht vor und Christoph: erklärt euch, was sich dahinter verborgen hat. Also los geht’s. „Die URL, so muss es sein, ist eine INNOQ Subdomain. Doch welche, das gilt es zu enthexen, bevor wir lustig mit Gewinnen klecksen. 6163323032310A. Ist das nicht einfach, unglaublich, super und wunderbar?”

Christoph: Ja, sehr schön. Vielen Dank. Das ist, glaube ich, noch der relativ einfache Teil. Da steht schon ziemlich viel drin, was man da machen muss. Scheinbar muss man irgendwie auf eine INNOQ Subdomain kommen. Und jetzt ist die Frage, welche ist das? Und das hast du gerade ja vorgetragen, da ist das Wort enthexen drin und dann kommen irgendwelche lustigen Zahlen. Und wenn man dann so von der Wortähnlichkeit oder von den Texten mal geht, dann könnte man sich vielleicht denken, dass das Zahlen in Hexadezimaldarstellung sind. Und wenn wir die dann umwandeln, dann bekommen wir einen schönen String und die setzen wir dann einfach vor die INNOQ Domain, also vor innoq.com Und dann sind wir schon den ersten Schritt weiter. Dann bekommen wir mal eine Webseite. Und dann geht das Rätsel weiter.

Lisa: Genau, auf der Webseite war glaube ich dann einfach nur ein Eingabefeld damals, oder?

Christoph: Ja, genau, da musste man das einmalige Geheimnis eingeben.

Lisa: Genau. Doch auf der Seite angekommen, ist der Berg noch nicht erklommen. Am 29. November ist eine Folge erschienen, sie wird euch beim Lösen des Rätsels dienen. Eine App, die wurde dort genannt. Habt sie am besten gleich zur Hand.

Christoph: Ja, das ist vielleicht noch nicht so eindeutig. Und das war eine gute Werbung, dass man noch mal unsere alten Folgen hört. Um das Thema Multi-Faktor Authentifizierung und Passwörter und soweiter. Und worauf da Bezug genommen wird, mit der App sind solche OTP Apps, die einem so einmalige Codes erzeugen, was man bei so einer typischen Zwei-Faktor Authentifizierung hat. Man gibt erst das Passwort ein und dann wird man typischerweise nach so einem sechsstelligen Code gefragt, den man dann eingeben kann. Und wir brauchen jetzt im weiteren Verlauf für das Rätsel dann auch so eine App. Das könnte zum Beispiel der Google Authenticator sein oder Authy oder auch von Microsoft. Das ist eigentlich fast egal. Aber warum das nur fast egal ist, dazu kommen wir dann gleich.

Lisa: Okay, dann hier der letzte Teil des Rätsels. Doch die App ist nicht euer einziger Favorit. Dort ist ein Code, den man nicht gleich sieht. QR, so heißt er ganz genau. InScan wäre jetzt sehr schlau. Tragt die einmaligen Zahlen geschwind ein. Vielleicht wird der Gewinn dann bald euer sein.

Christoph: Und da wird versucht zu zeigen, wo man denn die Konfiguration für die App herbekommt. Weil normalerweise muss ich da irgendwas eingeben, um die zu konfigurieren. Und das ist typischerweise so ein QR Code, den man scannen kann. Und deshalb ist es hier auch, dass da ein QR Code ist. Aber es wird da nicht so gesagt, wo der sich genau befindet, sondern den muss man suchen. Der ist nämlich ein bisschen versteckt worden von uns und daher gibt sich das dann auch mit den einmaligen Zahlen, weil das ist ein OTP, ein One Time Passwort. Das ist dann auch genau nur einmal gültig. Und den QR Code haben wir ein bisschen versteckt gehabt. Man kann ihn fast sehen, aber dann nur schwierig scannen, weil wir haben den QR Code im Favicon versteckt. Dieses kleine Bildchen, was neben der URL oder in den Tabs angezeigt wird. Und da ist er ein bisschen klein um den zu scannen. Aber da kann man sozusagen die Form erkennen, dass es wohl ein QR Code ist und dann muss man sich den versuchen rauszupicken. Das Einfachste ist, man sucht einfach im HTML nach der URL und schaut sich den in den Developer Tools an. Da kann man den dann auch direkt sehen oder wenn man die URL aufruft und das dann speichert, dann hat man dann ein Bild in einer vernünftigen Größe. Die ganz raffinierten, die versuchen auch mit dem Bildschirm Zoom den Favicon sehr hoch zu zoomen. Das gibt es, jedenfalls unter Macs, standardmäßig eingebaut, unter den Accessibility Tools. Unter Windows weiß ich das nicht, aber da gibt es wahrscheinlich sehr ähnliche Sachen auch unter Linux. Die Bildschirm Lupe. Und dann kann man sich das ranzoomen. Und ich hatte das auch mal probiert, aber das ist sehr schwer. Das hat nur ein einziges Mal geklappt, dass der das erkannt hat, weil das Problem ist, er skaliert das vorher runter für dieses Favicon. Und wenn man das zoomt, dann sind die Daten, die Skalierungsinformationen schon verloren gegangen. Da gibt es schon echte Probleme, aber theoretischerweise geht das auch. Wie gesagt, einmal ist mir das gelungen, also da muss man genau den richtigen Zoom Level haben und schauen. Das Einfachste ist auf dem Favicon das herauszusuchen. Am Quelltext erkennt man es dann nicht so genau, weil wir haben es natürlich nicht QR Code genannt, sondern Favicon, PNG oder JPEG oder so. Wenn man den Quelltext untersucht, findet man es nicht. Aber wie gesagt, wer ein bisschen aufmerksamer ist, der erkennt das vielleicht, da es auch Gewinner gab und auch eine ganze Reihe richtiger Einsendungen haben das wohl auch ein paar Leute gefunden.

Lisa: Genau. Du hattest eben noch angesprochen, dass es ein Problem gab mit diesen Authenticator Apps und dem Rätsel.

Christoph: Ja, genau. Ich hatte gerade gesagt, dass das eigentlich eine beliebige sein kann, aber das stimmte nicht ganz. Wir haben nämlich nicht die Standardeinstellungen, die da sonst benutzt werden. Dass so ein OTP aus sechs Zeichen besteht, genauer gesagt aus sechs Ziffern und dass das für 30 Sekunden gültig ist. Und in einem Barcode wird das normalerweise so codiert, aber das kann man auch ändern. Der Standard erlaubt das, dass es da auch anders geht. Und wir hatten das erhöht auf neun Sekunden bei der Anzahl der Ziffern, aber auf 15 Sekunden runtergesetzt bei der Zeit, dass man so ein bisschen Zeitdruck hat, während man das abtippt und sich nicht zu lahm ist. Und es hat sich herausgestellt, dass einige Apps damit nicht klar gekommen sind. Die haben dann einfach trotzdem nur diese sechs Ziffern und dann fehlten halt drei. Da hatten dann doch einige ein Bug dabei. Aber es gibt genügend Auswahl, an frei verfügbaren kostenlosen Apps, die man da nehmen kann. Und das sollte eigentlich auffallen und das hatten wir vorher auch gar nicht gewusst. Die zwei, die wir ausprobiert hatten, konnten das, aber nicht alle.

Lisa: Und das war die Lösung von Jahr 2021.

Christoph: Dann konnte man die eingeben und dann kam man dann auf eine weitere Seite, die sonst nicht zugänglich ist. Und da stand dann das, was man als Rätsels Lösung per Email an uns senden konnte, damit wir wissen, wer denn an dem Rätsel teilnehmen möchte. Und es gab da auch einige Einsendungen, die das auch relativ fix ganz richtig gemacht haben.

Lisa: Sehr cool. Dann würde ich sagen, geben wir zum Adventskalender 2022. Auch da haben wir das gleiche Spiel betrieben. Wir haben ein Gedicht vorgelesen am 24. Und dieses Gedicht hat auch hier einige Hinweise enthalten. Und wir machen das jetzt einfach wieder genauso. Ich habe so viel Spaß am Gedicht vorlesen. Du hast viel Spaß am Dinge erklären, also teilen wir das einfach wieder so auf. „Teil 1: Die Subdomain, sie ist versteckt. Was haben wir da nur ausgeheckt? Enthexen müsst ihr sie geschwind am Ende jeder Folge, die ihr findet.”

Christoph: Ja, das ist sehr analog zu dem, was wir in 2021 gemacht haben. Man muss wieder etwas enthexen. Diesmal sind aber die Zahlen, die man enthexen muss, nicht in dem Gedicht drin, sondern wir haben es so gemacht, wie es auch die guten Radiosender machen. Beim Gewinnspiel muss man die ganze Zeit hören, damit man da mitmachen kann. Und wir haben die am Ende der jeweiligen Folgen immer eingesprochen und sogar noch nach dem Abschluss Jingle. Das hast du das dann immer schön gemacht und hast die dann immer so eingesprochen. Eigentlich muss man dann auch eigentlich ganz durchhören. Gut, wer das System dann einmal verstanden hatte, konnte auch zum Ende des Audios springen. Oder man könnte dafür natürlich auch die Transkripte benutzen und sich das dann durchlesen. Weil wir wollten auch niemanden ausschließen, der vielleicht unsere Sachen nur lesen kann und gar nicht hören kann. Wir versuchen soweit das geht beim Podcast auch accessible zu sein und dann muss man sich die dann alle zusammen finden. In jeder Folge gab es 2 bis 3 Ziffern, die man dann zusammengesetzt hat und dann konnte man das wieder umwandeln in einen String aus den Hexadezimalzahlen und dann hatte man schon wieder eine Subdomain gefunden.

Lisa: Mein Highlight war übrigens das vollkommen durch Zufall an Nikolaus, also am 6. Dezember, 06 die Kombination war, die vorgelesen wurde.

Christoph: Oh, das ist mir gar nicht aufgefallen, dass das so passend war. Sehr gut.

Lisa: Genau. Und das war auch diesmal wieder so, dass wir ein Eingabefeld hatten und irgendwas eingeben mussten. Und ich möchte noch mal sagen, ich fand das INNOQ Logo ganz, ganz großartig. Danke an Sonja, weil ich hatte meinen Spaß damit. Es gab ein großartiges INNOQ Logo mit Lichterkette vor Tannenzweigen und es war einfach cool weihnachtlich. Weiter mit dem Hinweis: „In euren Köpfen, da fehlt etwas. Ein Kopf sollte sich anders artikulieren und neue Werte formulieren. Wie wäre es auch, ein Geheimnis zu akzeptieren?“

Christoph: Erst mal möchte ich mich auch noch mal an den Dank an Sonja anschließen. Ich fand das diesmal optisch auch sehr gelungen dabei. Man musste ein Geheimnis herausfinden. Und der Teil des Gedichtes, den du gerade jetzt vorgetragen hast, gibt Hinweise darauf, wo wir das finden und wie wir da drankommen. Und das erste Wichtige sind die Köpfe. Das ist ein Hinweis, wo das sein könnte. Und da gab es mehrere Sachen, wo die Leute dann gesucht haben, was alles so ein Hit ist. Das war ganz interessant. Wir wissen das von den Leuten, wir haben intern einen Betatest vorher gemacht, damit wir wissen, wir machen das nicht zu schwer und auch nicht viel zu einfach. Da haben wir das vorher mal verprobt, weil die Internen können sowieso leider nicht teilnehmen. Da konnte man schon mal ein bisschen schauen, ob das so passt. Und da haben wir die Information, wo Leute auch gesucht haben. Und das erste war so im HTML Head, also in dem HTML Quelltext gibt es auch ein Head Element und da haben die Leute gesucht. Das war aber vergeblich. Und das wird auch Plural genannt im Gedicht. Es sind die Köpfe, nicht der Kopf. Von daher war es das nicht. Andere hatten es sogar noch weitergetrieben, haben in irgendwelchen Metadaten von Bildern, Meta-Daten, weil es auch Header Dateien sind und geschaut und sonst was nicht. Bei so einer http Anfrage wird nicht nur das HTML zurückgeliefert, sondern es gibt auch immer irgendwelche Header. Und zwar beim Anfragen und bei der Antwort. Und darum sollte es sich drehen. Und dann kommt die Zeile: Ein Kopf sollte sich anders artikulieren. Das war ein Hinweis darauf, dass man einen dieser Header bei der Anfrage manipulieren sollte und dann einen entsprechenden Wert da reinschreibt. Und welcher Header gemeint ist und welcher Wert da rein soll, das ist dann der letzte Teil gewesen. Das wär: Wie wäre es auch ein Geheimnis zu akzeptieren? Und das kann man sogar sehr wortwörtlich nehmen, weil es gibt den Except Header und da wird reingeschrieben, was man für MIME Types akzeptieren würde als Client, ob das jetzt Text HTML ist oder plain Text oder JSON oder so. Der sollte halt diesmal auch Geheimnisse akzeptieren. Und dann konnte man da wortwörtlich ein Geheimnis reinschreiben in den Exepct Header. Und dann hat der Server darauf reagiert. Und da wir nicht so genau wussten, übersetzen die Leute das jetzt? Weil die ganzen Header sind in Englisch formuliert, haben wir auch Secrets erlaubt und auch den Plural haben wir erlaubt. Geheimnisse und Secrets. Und das war auch ganz gut, weil das war jedenfalls in unserem Betatest sehr unterschiedlich, wer da was genommen hat. Und dann hatte man den nächsten Schritt gemacht und dann geht das Gedicht aber noch weiter und gibt weitere Hinweise, was jetzt kommt. Jetzt habe ich erst mal nur eine Anfrage manipuliert. Man kommt jetzt aber nicht sozusagen direkt auf eine Lösungsseite.

Lisa: Und jetzt kommt die schlüssige Zeile aus dem Gedicht: Nehmt die Antwort genau unter die Lupe.

Christoph: Genau, und da musste man schauen. Und das war bei manchen unserer Beta Testerinnen auch gar nicht so einfach, weil die alles mögliche geschaut haben, im HTML wieder. Und das war 100% gleich. Sondern wir haben das da, ich will jetzt nicht sagen versteckt, aber da reingeschrieben, wo auch die Antwort auf Except Header hingehört. In den Content Type. Da steht dann jetzt auf einmal Secret drin und im Secret steht das Geheimnis, wenn man das in das Import Feld reinschreiben muss und dann abschicken muss. Aber das haben einige Leute überlesen, weil davor steht ganz normal Text HTML UTF8 und so. Und die Spec erlaubt so beliebige Attribute zu schreiben. Und wenn man das ans Ende geschrieben. Und wenn man das erst mal einfach scannt und da steht dann der Text HTML und alles sieht gut aus, dann brechen manche Leute scheinbar schon ab mit ihrem Parsing im Gehirn und lesen weiter und haben das dann übersehen, obwohl sie das eigentlich klar vor Augen hatten. Aber das ist dann einfach. Da steht dann secret= drin und dann hat man sozusagen das Geheimnis gefunden, das man dann eingeben kann. Und wenn man das macht, dann kommt man wieder auf eine Seite, die sonst nicht erreichbar ist. Und da steht dann wieder schön die Lösung, die man uns per Email geschickt hat, was auch wieder mehrere Hörerinnen ganz schnell geschafft haben. Die ersten kamen schon direkt am 24., kurz nachdem die Folge veröffentlicht war, war schon die erste Lösung da. Ich war sehr erstaunt, aber jetzt auch bis zum Einsendeschluss kam auch noch mal eine Lösung rein. Am Tag jetzt vor dem Einsendeschluss kam die letzte Lösung rein. Manche haben noch länger probiert oder die Folge später gehört, ich weiß es nicht, aber das hat ganz gut gepasst.

Lisa: Sehr cool. Danke fürs Auflösen, Christoph:. Ich glaube, das war eine gute Idee, dass wir das noch mal aufgenommen haben. Auch als Archiv für uns quasi, was wir schon als Rätsel gemacht haben.

Christoph: Das ist glaube ich ganz gut. Die Leute, die das jetzt noch nachträglich hören, können das dann auch mal probieren, die Seite noch ein bisschen online. Gewinnen könnt ihr nichts mehr. Wie gesagt, Gewinnerin ist schon benachrichtigt soweit. Der Einsendeschluss ist jetzt auch schon vorbei, wo wir das aufnehmen. Von daher geht das nicht. Und was ich ganz interessant fand, was ich dabei gelernt hat. Um diesen Except Header zu manipulieren, gibt es verschiedene Wege. Ich könnte jetzt sagen, ich nehme erstmal cURL. Das haben im Betatest die meisten Leute gemacht, die haben cURL benutzt dabei und das auf der Kommandozeile gemacht. Als ich das mit entworfen habe, habe ich das ausprobiert im Firefox. Da kann man in den Developer Tools diese Requests manipulieren. Man kann einen geschickten Request anklicken, den dann ein bisschen verändern und dann noch mal schicken, das geht. Und das geht auch im Safari. Aber komischerweise im Chrome, der die größte Marktdominanz hat und der angeblich die besten Developer Tools hat, da geht das nicht. Jedenfalls nicht so offensichtlich, dass ich das sofort gefunden hätte. Das erklärt auch vielleicht, weil das dann viele Leute, die das machen wollen, einfach mal cURL genommen hat. Das fand ich ganz interessant dafür, dass das sozusagen in den Minderheiten Browsern ganz einfach geht und in dem, der den Markt beherrscht, es nicht geht.

Lisa: Wieder was dazugelernt.

Christoph: Genau. Damit wollen wir es wohl mal belassen für heute. Eine inhaltliche Folge gibt es dann demnächst wieder schön frisch ins neue Jahr.

Lisa: Genau, danke Christoph:, dass du aufgelöst hast. Danke euch allen, dass ihr zugehört habt und hoffentlich auch mit gerätselt habt. Falls ihr Ideen habt oder Feedback habt, könnt ihr uns das gerne schicken an [email protected] und wir wünschen euch sehr verspätet ein frohes neues Jahr, einen guten Start ins neue Jahr und bis zum nächsten Mal. Tschüss.

Christoph: Ciao.

Türchen Nummer 24: Das Weihnachtsrätsel

Christoph: So Lisa, alle 24 Türchen sind geöffnet, ein Jahr ist wieder vorbei. Und was machen wir jetzt?

Lisa: Das ist einfach verrückt! Das ist eine gute Frage, was wir jetzt machen… Erstmal die Zeit genießen und keine Türchen mehr aufnehmen, würde ich sagen. Christoph: Ja, das ist schon mal 'ne ganz gute Idee. War ganz schön viel Arbeit. Aber wir können ja unsere Hörer:innen jetzt nicht einfach so entlassen. Ohne ihnen kompaktes Wissen zu präsentieren oder was anderes zu machen.

Lisa: Ja, das stimmt! Und dann hatten wir noch so ein Gewinnspiel versprochen, glaube ich. Und wir haben einfach nie gesagt, was man überhaupt gewinnen kann.

Christoph: Eigentlich hatten wir gehofft, die Hörer:innen vergessen das einfach, aber man kann das in der ersten Folge schon nachhören… Also schlecht, ne… Also müssen wir was machen, ne…!

Lisa: Ja, so ein Käse! Was gibt’s denn zu gewinnen, Christoph?

Christoph: Ja, zu gewinnen gibt es einen Platz in einem brandneuen Training “OWASP Top Ten in der Praxis” mit ganz vielen praktischen Übungen und das wird super!

Lisa: Das hört sich echt cool an! Meinst du, ich kann auch mitmachen?

Christoph: Jaaaa… Du bist leider vom Gewinnspiel ausgeschlossen. Also, alle INNOQ-Mitarbeiter sind leider nicht dabei, aber vielleicht ergibt sich ja sonst eine Gelegenheit.

Lisa: Dann hab ich nur die eine Idee: Ich mach das Rätsel extra schwer dieses Jahr, damit es einfach keiner hinkriegt und dann kann ich zu der Schulung gehen.

Christoph: Das ist auch eine Idee. Na ja dann… Was ist denn unser Rätsel?

Lisa: Wie letztes Jahr ein Gedicht. Sonst wär’s ja langweilig!

Christoph: Na dann: Leg mal los!

Sonja: Weihnachtszeit ist Rätselzeit, macht euch alle schnell bereit! Neben all dem Schnee und Eise Folgen nun die Hinweise

Lucas: So wie auch im letzten Jahr War es da nicht wunderbar?! Die Subdomain, sie ist versteckt Was haben wir da nur ausgeheckt?

Lisa: Enthexen müsst ihr sie geschwind Am Ende jeder Folge ihr sie find! Doch auf der Seite angekommen, Habt ihr noch lange nicht gewonnen!

Steffi: In euren Köpfen da fehlt etwas, macht es bisher nicht sehr viel Spaß?! Ein Kopf sollte sich anders artikulieren, und neue Werte formulieren!

Anja: Wie wär‘s auch ein Geheimnis zu akzeptieren, was sollte da jetzt schon noch passieren?! Nehmt die Antwort genau unter die Lupe, Dann bringt Knecht Ruprecht keine Rute!

Ute: Auch dieses Jahr war‘n wir am Reimen, man kann ein Rätsel nicht besser timen. Wir wünschen euch ganz viel Glück - die Weihnachtszeit, sie ist verrückt!

Lisa: Tja, ein Gedicht, wie letztes Jahr… Ich hoffe mal, dass ihr es echt schwer habt, aber ich hoffe auch irgendwie, dass ihr es schafft, damit ihr diesen coolen Platz in der Schulung gewinnen könnt. Genau, was bleibt mir noch zu sagen?! Vielen, vielen, vielen Dank, dass ihr dabei wart, dass ihr zugehört habt, dass ihr mit uns die Türchen im Advent geöffnet habt. Und wir wünschen euch frohe Feiertage, einen entspannten Urlaub, wenn ihr welchen habt und einen guten Rutsch ins neue Jahr mit hoffentlich vielen neuen Episoden im kommenden Jahr! Bis dahin.

Türchen Nummer 23: Deepfakes

Künstliche Intelligenz und maschinelles Lernen sind eines der IT-Themen in den letzten Jahren. Deep Learning, bei dem komplexen neuronale Netze mit sehr vielen Schichten verwendet werden, ist dabei besonders populär, da, obschon die unterliegende Technik schon lange bekannt ist, erst seit Kurzem die, für mehr als triviale neuronale Netze, nötige Rechenleistung zur Verfügung steht. Und die Ergebnisse werden immer beeindruckender.

Ein Anwendungsgebiet für Deep Learning sind Deepfakes. Deepfakes sind mittels neuronale Netzwerke erstellte oder manipulierte Bild-, Video- oder Audioaufnahmen, die kaum bis gar nicht mehr von echten unterschieden werden können. Ein häufiger Einsatz von Deepfakes ist das Ersetzen von Gesichtern in Videoaufnahmen oder das Replizieren von Stimmen.

Neben harmlosen Scherzen, wie das Ersetzen des eigenen Gesichts durch das eines Prominenten, kommen Deepfakes zum Leidwesen vieler Prominenter, darunter vor allem Frauen, auch oft in der Schmuddelecke des Internets zur Anwendung.

Eine der größten Gefahren durch Deepfakes im Bereich IT-Security ist ausgefeiltes Social Engineering, um bestimmte Personen dazu zu bringen, Dinge zu tun, die sie eigentlich nicht tun sollten. Insbesondere geheime Informationen preiszugeben.

Social Engineering ist eine schon lang eingesetzte Technik, um in IT-Systeme einzudringen. Einer der berühmtesten Hacker der Welt, Kevin Mitnick, früher Black Hat, heute White Hat, hat nach eigener Aussage ausschließlich Social Engineering eingesetzt, um in IT-Systeme einzudringen. Neben dem klassischen Capture-the-Flag Wettbewerb wird auf der jährlich stattfindenden DEFCON Konferenz, einer der größten Hacker Konferenzen der Welt, auch ein Social Engineering Capture-the-Flag Wettbewerb ausgetragen.

Warum sind Social Engineering Angriffe mit Deepfakes so gefährlich? Im Vergleich zu gefakten E-Mails oder Anrufen von Unbekannten sind Audio oder Video-Nachrichten mit den Stimmen und Gesichtern von Kolleg:innen oder leitenden Personen wesentlich glaubwürdiger. Über das Faken von leitenden Personen ist es auch deutlich leichter Handlungsdruck aufzubauen. Die Erfolgsaussichten sind somit merklich besser. Betrüger:innen waren schon mit Deepfakes beim CEO-Fraud, dem Ausgeben als Vorgesetzte, erfolgreich.

Die Möglichkeiten zur Manipulation in Echtzeit sind noch begrenzt, daher sind Video- oder Audioanrufe mit Deepfakes heute zum jetzigen Zeitpunkt nicht besonders praktikabel. Aber es ist wahrscheinlich nur eine Frage der Zeit, dass auch Deepfakes in Echtzeit erstellt werden können, die nicht mehr erkennbar sind.

Was könnt ihr tun, um euch gegen Deepfakes zu schützen? Am besten ihr vergewissert euch bei den vorgeblichen Kolleg:innen und leitenden Personen, indem ihr euch unter euch bekannten Kontaktdaten bei ihnen meldet. Am besten per Echtzeitinteraktion wie einem Video- oder Telefonanruf. Wer den Aluhut in XL trägt, oder besonders gefährdet ist, sollte vorher, bei einem Treffen von Angesicht zu Angesicht, ein Codewort ausmachen, dass die Betrüger:innen nicht wissen können, und im Zweifel danach fragen.

Wenn man die Entwicklungen bei Deepfakes und anderen Anwendung der künstlichen Intelligenz wie dem Chatbot chatGPT zusammen denkt, kann einem angst und bange werden, was in Zukunft in Sachen automatisiertem Social Engineering möglich wird. Die massenhaft versendete Scam-Mail von heute mutet dagegen wie die Steinzeit an.

Zum Schluss bleibt noch eine Frage. Hat das hier wirklich Stefan eingesprochen oder war es nur ein Deepfake? Da müsst ihr ihn wohl selber fragen.

572

Türchen Nummer 22: Hardening

Eisenwerkstoffe können gehärtet werden und IT-Systeme auch. In beiden Fällen geht es darum, die Widerstandsfähigkeit zu erhöhen. Doch um Eisenwerkstoffe wollen wir uns heute nicht kümmern, wir bleiben bei den IT-Systemen. Auch im IT-Kontext ist im deutschen Sprachraum die wörtliche Übersetzung ‘härten’ gebräuchlich. Beim Hardening von IT-Systemen, geht es darum, einerseits die Angriffsoberfläche zu minimieren und andererseits das Schadenspotenzial eines erfolgreichen Angriffs zu begrenzen.

Für die Minimierung der Angriffsoberfläche gibt es zahlreiche Maßnahmen. In Betriebssystemen sollten nicht benötigte Dienste abgeschaltet und Dateisysteme verschlüsselt werden. Außerdem sollten Anti-Exploit-Techniken wie Adress-Space-Layout-Randomization oder Write XOR Execute Memory Protection aktiviert werden. Bei Infrastruktur-Komponenten wie Datenbanken, Webservern, Caches usw. sollten die Standardnutzungskonten und Standardpasswörter deaktiviert, beziehungsweise geändert, werden. Generell sollten nur verschlüsselte Verbindungen angenommen werden. Die Applikation selber sollte, soweit es geht, auch mit Anti-Exploit-Techniken kompiliert werden, etwa Stack Canaries oder Control-Flow Integrity. Falls die Applikation in einer Programmiersprache geschrieben ist, die nicht zu nativem Code kompiliert, sollte der Interpreter oder die VM, die den Code ausführt, mit Anti-Exploit-Techniken kompiliert sein.

Auch das Schadenspotenzial eines erfolgreichen Angriffs kann durch eine Vielzahl von Maßnahmen begrenzt werden. Betriebssysteme können unter anderem Applikationen mit minimalen Rechten ausführen, einzelne Programme durch Techniken wie Chroot, Jails oder Container voneinander isolieren oder die erlaubten Betriebssystemaufrufe mit Techniken wie seccomp unter Linux beschränken. In der Applikation können lesende und schreibende IO-Operationen voneinander getrennt werden. Teile einer Applikation können in einer Sandbox ausgeführt werden, so wie es etwa Webbrowser machen, die einzelne Tabs in getrennten Sandboxes ausführen.

Warum wird Software eigentlich nicht immer in einem gehärteten Zustand ausgeliefert? Der Grund dafür ist Convenience. Ein System, das out-of-the-box funktioniert, ist für Entwickler:innen immer einfacher, und deshalb auch beliebter als ein System, das erst aufwendig konfiguriert werden muss. Die out-of-the-box Experience gelingt allerdings im Regelfall nur mit Standardnutzungskonten und Standardpasswörtern, Verzicht auf Verschlüsselung, ausufernden Rechten und Installation sowie Aktivierung von allen potenziell irgendwann mal gebrauchten Komponenten. Also dem Gegenteil von Hardening.

Das aus Türchen Nummer 6 bekannte OpenBSD ist ein positives Beispiel für ein gehärtetes System. Im Auslieferungszustand werden nur zum Betrieb essenzielle Dienste gestartet, alle anderen müssen explizit gestartet werden. OpenBSD bringt viele Anti-Exploit-Techniken wie Adress-Space-Layout-Randomization, Position Independend Executeables, Stack Canaries oder Write XOR Execute Memory Protection mit, genauso wie Techniken zur Schadensbegrenzung bei erfolgreichen Angriffen, etwa Chroot-Jailing, Privilige Separation und Privilige Revocation.

Das Gegenteil von gehärteten Systemen sind JavaScript Applikationen, die per npm dreiviertel des Internets installieren. Anstatt die Angriffsoberfläche zu minimieren, wird die Angriffsoberfläche vervielfacht.

Hardening gehört zu den Basics, wenn ihr sichere Systeme bauen wollt. Für die verschiedenen Betriebssysteme findet ihr im Netz zahlreiche Leitfäden fürs Hardening. Auch bei den meisten Infrastruktur-Komponenten, wie Webserver, Datenbanken, Message-Queues oder Caches seid ihr nicht die Ersten mit dieser Herausforderung und könnt auf vorhandenes Wissen zurückgreifen. Also los, worauf wartet ihr noch?

656

Türchen Nummer 21: Darkweb, Darknet und das Tor-Netzwerk

Am 21. Dezember ist der National Flashlight Day in den USA. Taschenlampen sind äußerst nützlich, um sich im Dunkeln zurechtzufinden oder Dinge zu beleuchten. Für das Darkweb funktioniert das leider nicht, deshalb übernehmen wir das jetzt.

Als Darkweb oder auch Darknet wird der Teil des Internets bezeichnet, der nicht über die üblichen Suchmaschinen erfasst wird, meistens auch nicht direkt zugänglich ist, und in dem besonders auf die Anonymität bei der Nutzung geachtet wird. Im einfachsten Fall handelt es sich um Dienste im Internet, die nur mit den richtigen Zugangsdaten genutzt werden können. Anonymität wird durch das Nutzen von VPNs erreicht, und liegt in der Verantwortung der Nutzer:innen. Der weitaus größte Teil des Darknets ist jedoch nicht direkt im Internet erreichbar, sondern nur durch das Tor-Netzwerk.

Tor, the onion routing network, ist ein Netzwerk von Servern, auch Knoten genannt, die es Nutzer:innen ermöglichen, anonym im Internet zu surfen, sodass ihre Online-Aktivitäten nicht von Dritten verfolgt werden können. Bei der Verwendung von Tor werden Verbindungen über mehrere Server im Tor-Netzwerk umgeleitet, wodurch die Herkunft der Anfrage und das Ziel verborgen bleiben. Verbindungen über das Tor-Netzwerk laufen mindestens über drei Knoten, den Eingangsknoten, den Ausgangsknoten und im Prinzip beliebig viele weitere Knoten, wobei es in der Praxis normalerweise nicht mehr als drei Knoten sind, um Ressourcen zu schonen und eine akzeptable Latenz zu erreichen. Die einzelnen Knoten kennen dabei nur ihren vorausgehenden und nachfolgenden Knoten. Im Falle des Eingangsknotens ist der vorausgehende Knoten der Client der Nutzer:in, beim Ausgangsknoten ist der nachfolgende Knoten das Ziel, welches die Nutzer:in ansurfen möchte.

Neben anonymen Verbindungen zu Webseiten und Diensten erlaubt das Tor-Netzerk auch, Dienste und Webseiten bereitzustellen, die nur über das Tor-Netzwerk erreichbar sind. Diese werden onion oder hidden services genannt. Die Anonymität ist dabei bidirektional. Die Betreiber der Webseiten und Dienste können nicht die IP-Adressen ihrer Nutzer:innen sehen, und diese können nicht die IP-Adressen der Webseiten und Dienste sehen. Adressiert werden die Webseiten mit einer Kombination aus dem Hash eines kryptografischen Schlüssels, den die Webseite und Dienste vorher in den Directory-Diensten des Tor-Netzwerks publiziert haben, und der pseudo Top-Level-Domain “.onion”, die nur im Tor-Netzwerk erreichbar ist.

Wozu kann man das Darkweb nun nutzen? Einerseits können mittels Tor Journalist:innen, Aktivist:innen und andere gefährdete Personen der Zensur und Überwachung in repressiven Regimen entgehen. Andererseits kann das Tor-Netzwerk auch für illegale Zwecke genutzt werden, beispielsweise als Marktplatz für Waffen und Drogen.

Auch im Bereich IT-Security wird das Tor-Netzwerk genutzt, etwa um die Herkunft von Hacking-Angriffen zu verschleiern. Es gibt auch etliche Marktplätze, auf denen die Beute von Black Hats erworben werden können wie gestohlene Kreditkartendaten, Authentifizierungsdaten oder Malware. Ransomware-Gruppen und Bot-Net-Betreiber bieten ihre Dienste normalerweise auch nur im Darknet an.

Es ist wichtig zu wissen, dass TOR keine hundertprozentige Anonymität garantieren kann, auch wenn es darauf ausgelegt ist, dass einzelne Knoten auch von Adversaries betrieben werden können. Mit genügend Überwachungskapazität, wenn ein Adversary etwa eine Mehrheit aller Tor-Knoten betreiben würde, wäre es möglich, über zeitliche Korrelationen von Aktivitäten auf Eingangs- und Ausgangsknoten, Nutzer:innen zu de-anonymisieren.

Wenn ihr zu Weihnachten noch eine Idee für eine gute Tat braucht, dann könntet ihr überlegen, selber einen Tor-Knoten zu betreiben oder dem Tor-Projekt eine Spende zukommen zu lassen. Journalist:innen, Aktivist:innen und andere gefährdete Personen werden es euch danken.

E64

Türchen Nummer 20: Capture-the-Flag

Am 20. Dezember wird in Großbritannien der Games-Day gefeiert. Auch Hacker und Häcksen spielen gerne, nicht nur in Großbritannien, sondern in der ganzen Welt. Besonders gerne spielen sie Capture-the-Flag, oder kurz CTF. Allerdings nicht das CTF, das man klassischerweise draußen spielt und das im deutschsprachigen Raum als Fahnenraub bekannt ist. Ebenso wenig wie die CTF-Modi, die zahlreiche Videospiele, vor allem Ego-Shooter, bieten.

In der IT-Security ist ein Capture-the-Flag ein Wettbewerb, in dem Hacker und Häcksen ihre Fähigkeiten beweisen können. Das Spektrum der im Wettbewerb benötigten Fähigkeiten ist dabei sehr breit und geht vom Programmieren und Reverse Engineering über Kryptografie bis hin zum Knacken und Entschlüsseln von kryptischen Hinweisen und Rätseln.

Capture-the-Flags können in etlichen Modi gespielt werden. Die zwei populärsten davon sind Attack/Defense und Jeopardy. Ziel ist bei allen Modi, wie der Name schon sagt, Flaggen zu erobern. Die Flaggen sind dabei natürlich nur virtuell, und typischerweise einfach Zeichenketten, die, wenn man sie kennt, beweisen, dass man die Flagge erobert hat.

Im Modus Attack/Defense treten zwei Teams gegeneinander an, um in die IT-Systeme des:der anderen einzudringen und die eigenen IT-Systeme zu verteidigen. Die, meist virtuellen, IT-Systeme für beide Teams werden dabei von den Veranstalter:innen des CTFs gestellt. Ebenso werden die Flaggen auch von den Veranstalter:innen auf den Systemen platziert. Im Auslieferungszustand haben die Systeme diverse Schwachstellen. Die Teams versuchen nun, sobald das CTF gestartet wird, die eigenen Systeme abzudichten, damit die eigenen Flaggen nicht erobert werden können, und gleichzeitig in die gegnerischen Systeme einzudringen, um dort die Flaggen zu erobern. Punkte gibt es sowohl für die Verteidigung der eigenen als auch für das Erobern der gegnerischen Flaggen. Die einfachste Verteidigung ist, einfach die eigenen Systeme herunterzufahren. Der Spaßfaktor bei einem Attack/Defense-CTF, in dem alle Systeme heruntergefahren sind, ist allerdings sehr überschaubar. Daher gibt es auch Punkte für die Verfügbarkeit der Systeme, sodass man durch einfaches Herunterfahren der Systeme nicht gewinnen kann.

Im Modus Jeopardy müssen verschiedene Challenges gelöst werden. Dabei können sowohl Teams als auch Einzelpersonen antreten. Für das Lösen einer Challenge erhält man eine Flagge. Bei einer Challenge kann die Flagge zum Beispiel im Dateisystems eines Webservers liegen, die über eine Directory-Traversal-Lücke erreicht werden kann. Bei einer anderen Challenge ist die Flagge in einer verschlüsselten Datei versteckt, die Implementierung der Verschlüsselung ist jedoch fehlerhaft, sodass der geheime Schlüssel rekonstruiert werden kann. Die Möglichkeiten sind sehr vielfältig, und bei vielen Challenges ist nicht immer sofort klar, wo die Flagge versteckt, und was genau zu tun ist. Zwar gibt es Hinweise, allerdings oft in der Form von Rätseln. Mit fortschreitender Spielzeit werden mehr und einfacher verständliche Hinweise veröffentlicht. Exploration sowie Trial-and-Error gehören aber in jeden Fall dazu. Punkte gibt es für jede Flagge, im Regelfall differenziert nach Schwierigkeit der Challenge. Auch Schnelligkeit wird belohnt, je schneller man eine Challenge löst, und desto weniger Hinweise benötigt wurden, desto mehr Punkte gibt es. Häufig ist es auch so, dass erst, wenn man eine Challenge gelöst hat, die nächste freigeschaltet wird.

Die DEFCON, einer der größten Hacker:innen-Konferenzen weltweit, hat das CTF populär gemacht. Heute gibt es auf vielen Security-Konferenzen ein begleitendes CTF. Auch außerhalb dieser Konferenzen werden fast jede Woche irgendwo CTFs gespielt, die frei zugänglich sind. Einige IT-Security Firmen setzen CTFs fürs Recruiting ein.

Wenn ihr auch mal ein CTF spielen wollt, gibt es Webseiten, auf denen ihr Informationen zu anstehenden CTFs bekommt. Werft mal einen Blick in die Shownotes. Falls ihr kein ganzes Wochenende, so lange gehen CTFs gemeinhin, opfern wollt oder könnt, dann sind viele CTFs auch noch im Nachhinein spielbar. Zwar ohne Punkte, dafür aber ohne Wettbewerbsdruck. Dann kann man in Ruhe seine Fähigkeiten verbessern. Vielleicht eine Gelegenheit für euch, dem Weihnachtsstress zu entfliehen.

696

Türchen Nummer 19: Namensverwirrung Nummer 3 – Cross-Site-Scripting

Cross-Site-Scripting, kurz XSS, ist ein Angriff auf Web-Applikationen, bei dem bösartiger JavaScript-Code in den Browser der Nutzer:innen eingeschleust wird, um etwa Nutzer:innen- und Authentifizierungsdaten zu stehlen oder die Ausführung der Web-Applikation im Browser zu manipulieren. Es gibt vier Typen von XSS-Angriffen: persistente, reflektierende, DOM-basierte und universelle.

Persistente XSS-Angriffe werden über die permanente Speicherung von bösartigem JavaScript-Code in der betroffenen Web-Applikation durchgeführt. Der bösartige JavaScript-Code wird dann jedes Mal an den Browser ausgeliefert und von ihm ausgeführt, wenn Nutzer:innen die betroffene Web-Applikation besuchen.

Reflektierende XSS-Angriffe hingegen nutzen Eingaben der Nutzer:innen, die ungefiltert und nicht encoded zurück an die Nutzer:innen gegeben werden. Das ist unter anderem der Fall, wenn bei einer Suchfunktion, der Suchbegriff wieder auf der Ergebnisseite ausgegeben wird. Ist der Suchbegriff JavaScript-Code und wird nicht encoded wieder ausgegeben, wird dieser auch vom Browser ausgeführt. Da Nutzer:innen sich in der Regel nicht selbst angreifen, muss man ihnen die manipulierten Eingaben irgendwie unterschieben. Eine Möglichkeit dafür ist, ihnen Links zu schicken, die die manipulierten Eingaben als Query- oder Path-Parameter enthalten.

DOM-basierte XSS-Angriffe werden direkt im Document Object Model (DOM) der betroffenen Web-Applikation durchgeführt. Im Gegensatz zu persistenten und reflektierenden Angriffen muss der bösartige JavaScript-Code dabei nicht mal zum Server gehen. URI-Fragmente können beispielsweise bösartigen JavaScript-Code enthalten. Diese werden nicht an den Server gesendet, sondern rein auf der Client-Seite verarbeitet. Manche Single-Page-Apps nutzen URI-Fragmente, um einen bestimmten State wiederherzustellen, wenn sie verlinkt werden. Ähnlich wie bei reflektierenden XSS-Angriffen, schickt man den Nutzer:innen Links, die manipulierte URI-Fragmente enthalten.

Universelles XSS ist ein Sonderfall unter den XSS-Angriffen. Hier sind nicht direkt die Web-Applikationen angreifbar, sondern es werden Sicherheitslücken in den Browsern ausgenutzt, um die Isolation von JavaScript-Code verschiedener Webseiten auszuhebeln. Eine Seite mit bösartigem JavaScript-Code kann diesen dann in anderen Webseiten ausführen. Hier hilft nur ein Update des Browsers auf eine abgesicherte Version durch die Nutzer:innen.

Wo ist nun die Namensverwirrung? Über Webseiten hinweg wird bei XSS gar kein JavaScript-Code ausgeführt, wie der Name suggeriert. Es handelt sich viel mehr um eine Code-Injection in den Browser der Nutzer:innen über eine Webseite. In der aktuellen 2021er OWASP Top 10 wurde XSS auch Teil von Code-Injection, und wird nicht mehr als eigenständiges Risiko geführt, so wie es in den vorigen Ausgaben der OWASP Top 10 der Fall war. Woher kommt dann der Name XSS, wenn es eigentlich eine Code-Injection ist? Das liegt daran, dass mit XSS ursprünglich eine ganz andere Art von Sicherheitslücke bezeichnet wurde. In der Anfangszeit von HTML und Browsern war es möglich, über Webseiten hinweg JavaScript auszuführen. Zum Beispiel bei der Verwendung von HTML-Frames. Angreifer:innen konnten versuchen, Nutzer:innen auf Webseiten zu locken, die bösartigen JavaScript-Code in unsichtbaren Frames geladen hatten, um die legitimen Seiten im für die Nutzer:innen sichtbaren Frame zu manipulieren und dort Daten abzugreifen. Diese Art von Angriff hat den Namen Cross-Site-Scripting bekommen. Da die Abkürzung CSS schon von Cascading-Style-Sheets belegt war, hat man sich entschieden Cross-Site-Scripting mit XSS abzukürzen, da ein X wie ein auf die Seite gestelltes Kreuz, im englischen Cross, aussieht. Die Browser-Hersteller haben darauf mit der Same-Origin-Policy reagiert. Damit kann JavaScript nur noch auf Ressourcen von der gleichen Origin zugreifen und XSS-Angriffe im klassischen Sinn waren somit nicht mehr möglich. Nur universelle XSS-Angriffe sind noch Angriffe im Sinne der klassischen Bedeutung, da sie auf Bugs in der Implementierung der Same-Origin-Policy abzielen. Im Laufe der Zeit wurden dann alle Angriffe, bei denen bösartiger JavaScript-Code im Browser ausgeführt wird, als XSS bezeichnet. So sind wir bei der heutigen Bedeutung von XSS angekommen.

Gegen Cross-Site-Scripting könnt ihr euch durch zwei Maßnahmen schützen. Erstens solltet ihr alle Daten, die eure Web-Applikation entgegennimmt, validieren und ggf. ablehnen, wenn sie nicht euren Erwartungen entsprechen. Zweitens solltet ihr alle Daten, die ihr an eure Nutzer:innen ausgebt, dem Kontext entsprechend encoden. Mehr dazu könnt ihr in unserer Folge “Input Validation, Output Encoding - Keine Kür, sondern Pflicht” nachhören.

265

Türchen Nummer 18: IT-Security Farbenlehre, Teil II – Black, Grey und White Hat

Mit dem Begriff Hacker wurden ursprünglich Personen bezeichnet, die sich geschickt, intellektuell und kreativ mit IT-Systemen auseinandersetzen, und diese für außergewöhnliche und vorher nicht angedachte Zwecke nutzen. Im Mainstream wird Hacker oft fälschlicherweise mit Krimineller gleichgesetzt, der seine außergewöhnlichen Fähigkeiten im Umgang mit IT-System dazu nutzt, sich illegal, und zu eigenem Vorteil, Zugriff zu Daten und Diensten zu verschaffen.

Wenn es um die Sicherheit von IT-Systemen geht, können die verschiedenen Arten von Hackern besser und präziser mit den Begriffen Black, Grey und White Hat beschrieben werden.

White-Hat-Hacker, manchmal auch Ethical-Hacker genannt, nutzen ihre Fähigkeiten, um Sicherheitslücken in IT-Systemen aufzudecken und zu beheben. Sie werden oft von Unternehmen, Organisationen oder Behörden beauftragt, ihre Systeme auf Schwachstellen zu überprüfen, z. B. in der Form von Pen-Tests. Ihr Ziel ist es, die Sicherheit von IT-Systemen zu verbessern. Sie agieren dabei im Rahmen der Gesetze.

Black-Hat-Hacker, seltener auch als Cracker bezeichnet, sind hingegen diejenigen, die illegal in IT-Systeme eindringen und sich unberechtigten Zugriff auf Daten und Dienste verschaffen, um Schaden anzurichten oder zu ihrem finanziellen Vorteil.

Grey-Hat-Hacker sind eine Mischform aus Black und White-Hat-Hacker. Genauso wie White Hats nutzen ihre Fähigkeiten, um Sicherheitslücken in IT-Systemen aufzudecken. Auch ihr Ziel ist die Verbesserung der Sicherheit von IT-Systemen. Wie Black Hats agieren sie dabei häufig außerhalb der Gesetze bzw. in rechtlichen Grauzonen. Gerade in Deutschland macht der berühmt-berüchtigte Hackerparagraf, den ihr letztes Jahr hinter Türchen 7 kennengelernt habt, ein Agieren innerhalb der Gesetze schwer. Grey-Hats arbeiten typischerweise nicht im direkten Auftrag der Unternehmen, Organisationen und Behörden, bei denen sie Sicherheitslücken aufdecken. Und sind auch nicht immer so verschwiegen, wie sich manche Betroffene es wünschen. Im deutschsprachigen Raum bezeichnen sich viele Grey Hats auch als Sicherheitsforscher.

Gerüchteweise soll so manch ein Hacker, der bei Tag ein White Hat ist, in der Nacht zum Grey oder gar Black Hat mutieren.

Was macht ihr nun damit? Ganz einfach, White Hats solltet ihr für euer Security-Team einstellen, damit sie Black Hats abwehren. Und mit Grey Hats solltet ihr ein gutes Verhältnis anstreben, und mit Dank auf gemeldete Sicherheitslücken reagieren, statt mit rechtlichen Schritten, wie es leider noch zu allzu häufig vorkommt. Das führt allerdings meisten nur dazu, dass euch niemand mehr Sicherheitslücken meldet. Sie verschwinden dadurch jedoch nicht. Die Black Hats wird es freuen. Langfristig lohnen sich Bug-Bounty-Programm Kosten vielleicht mehr als Anwaltskosten.

2D7

Türchen Nummer 17: log4shell – ein Jahr danach

Vor einem Jahr haben wir euch an dieser Stelle von der Sicherheitslücke log4shell berichtet, die kurz zuvor veröffentlicht wurde. Grund genug uns anzuschauen, was seitdem passiert ist und was wir daraus lernen können.

Leider ist log4shell nach einem Jahr immer noch weitverbreitet und wird erfolgreich ausgenutzt, das zeigen verschiedene Berichte und Studien. Noch rund ein Viertel aller log4j Downloads von Maven Central sind ungepatched und somit verwundbare Versionen. Auch wird im Netz noch massenweise mit automatisierten Scans nach verwundbaren Web-Applikationen gesucht.

Solange die aus Türchen 14 bekannten APT-Gruppen noch mit schon längst bekannten Lücken, wie log4shell, IT-Systeme infiltrieren können, haben sie es sehr leicht. Sie müssen dann nicht ihre wertvollen Zero-Days einsetzen, mit der Gefahr, dass diese danach verbrannt sind. Wozu die kompliziertesten Sicherheitssysteme an der Tür überwinden, wenn das Fenster offen steht? Auch die zahlreichen Ransomware-Gruppen, die enorme wirtschaftliche Schäden verursachen, haben ein leichtes Spiel, wenn bekannte Sicherheitslücken nicht gepatcht sind.

Die Cybersecurity & Infrastructure Security Agency, kurz CISA, betreibt seit 2021 den Known Exploited Vulnerabilities Catalog, in dem Schwachstellen gesammelt werden, von denen bekannt ist, dass sie aktiv ausgenutzt werden. Die dort aufgelisteten Schwachstellen sind zum Teil schon jahrelang bekannt und gepatcht. Log4shell ist mit jetzt knapp über einem Jahr regelrecht jung.

Was können wir also daraus lernen? Das Erstellen von SBOMs, das Fuzzen eurer Software und Pen-Tests zeigen euch nur, wo ihr verwundbar seid. Essenziell wichtig ist es jedoch, dass ihr Lücken auch zeitnah schließen könnt. Dazu müsst ihr in der Lage sein, jederzeit schnell und sicher zu deployen. Oder schnell und sicher Updates mit einem adäquaten Updatemechanismus zur Verfügung zu stellen, falls ihr keine Web-Applikationen, sondern Rich-Clients oder Embedded-Software entwickelt.

174

Türchen Nummer 16: IT-Security Farbenlehre – Red vs. Blue

Red und Blue Teams kommen ursprünglich aus dem US-Militär. In Rollenspielen und Übungen sind die Red Teams dabei die Angreifer:innen, die Blue-Teams die Verteidiger:innen. Das Red in Red Team spielt auf die rote Fahne der UdSSR an, da Red/Blue-Teaming während des Kalten Krieges entstanden ist. In der UdSSR soll die Farbgebung umgekehrt gewesen sein, da haben die Red Teams verteidigt und die Blue Teams angegriffen.

In der Welt der IT-Security werden Red Teams und Blue Teams für Übungen und Simulationen verwendet, die darauf abzielen, die Fähigkeiten und die Schwachstellen von Computer-Netzwerken und Sicherheitssystemen zu testen. Das Red Team schlüpft dabei in die Rolle der Angreifer:innen, sie versuchen, in das Netzwerk einzudringen, um es zu schädigen oder auszuspionieren. Die Verteidiger:innen im Blue Team hingegen haben die Aufgabe, das Netzwerk zu schützen und die Angriffe des Red Teams abzuwehren. Die Übungen dienen dazu, das Blue Team zu schulen und zu testen. Damit soll sichergestellt werden, dass Bedrohungen schnell erkannt und bekämpft werden können, sowie dass Schwachstellen im Netzwerk identifiziert und behoben werden.

Blue Teams setzen sich aus den internen Sicherheitsexpert:innen einer Organisation zusammen, und rekrutieren sich in der Regel, soweit vorhanden, aus dem Security Operations Center, dem Network Operations Center und dem Computer Emergency Response Team. Für das Red Team gilt das genauso, nur dass hier auch externe Expert:innen hinzugezogen werden können.

Vielleicht meint ihr, Ähnlichkeiten mit dem Pen-Testing aus Türchen Nummer 10 zu erkennen. Da liegt ihr nicht falsch, Pen-Testing und Red/Blue Teaming überschneiden sich in einigen Punkten. Beide versuchen, Schwachstellen in Computer-Netzwerken zu identifizieren und nehmen dafür auch die Rolle der Angreifer:innen ein. Beim Red/Blue-Teaming geht es aber im Gegensatz zum Pen-Testing vorrangig darum, die Abwehrfähigkeit und Resilienz bei konkreten Angriffen zu testen. Obendrein gibt es die Red und vor allem die Blue Teams für gewöhnlich dauerhaft in einer Organisation und nicht immer weiß das Blue Team, wann und wo das Red Team zuschlägt, während Pen-Tests nur zu bestimmten Zeitpunkten durchgeführt werden, die dem Security Operations Center, dem Network Operations Center und dem Computer Emergency Response Team bekannt sind.

Dauerhafte Red/Blue Teams leisten sich im Allgemeinen nur sehr große Organisationen. Aber auch in kleineren Organisationen müsst ihr nicht unbedingt darauf verzichten. Ihr könnt etwa ein Red/Blue Teaming mit eurem Team gegen ein anderes Team eurer Organisation machen. Für einen bestimmten Zeitraum, beispielsweise 6 Wochen, schlüpft ihr sowohl in die Rolle des Red Teams, und versucht die Systeme des anderen Teams anzugreifen. Gleichzeitig übernehmt ihr auch die Rolle des Blue Teams für eure Systeme. Das andere Team macht es genauso, es versucht seine Systeme zu schützen und eure anzugreifen. Dabei merkt ihr recht zügig, wo es z. B. beim Monitoring hapert, wenn ihr die Angriffe gar nicht erst bemerkt. Auch wie resilient euer System ist, oder ob vielleicht leicht auszunutzende Sicherheitslücken in euren Systemen schlummern, findet ihr unter Umständen heraus. Ihr solltet dies allerdings nicht unbedingt auf den Produktivsystemen machen. Eine Absprache mit eurer Organisation schadet auch nicht.

686

Türchen Nummer 15: Zero-Trust

Zero-Trust ist ein IT-Sicherheitsmodell, das in den letzten Jahren immer populärer geworden ist. Es definiert sich vor allem durch die Abwendung und Abgrenzung vom bisher vorherrschenden Sicherheitsmodell der Perimeter-Security. Daher wird es gelegentlich auch als Perimeterless-Security bezeichnet.

Der Begriff Zero-Trust wurde 2010 von John Kindervag geprägt, damals bei Forrester Research tätig, auch wenn die Probleme der klassischen Perimeter-Security schon lange bekannt waren, genauso wie mögliche Mitigationen, nur nicht unter dem Namen Zero-Trust. Im Artikel “Security in a world without borders” von 2004 beschreibt beispielsweise Joanne Cummings unter dem Stichwort “de-perimeterization” bereits viele Bestandteile des Zero-Trust Modells.

In der klassischen Perimeter-Security werden Nutzer:innen und Geräte, die sich innerhalb eines bestimmten Netzwerks befinden, generell als vertrauenswürdig angesehen. Moderne IT-Architekturen sind für dieses einfache Vertrauensmodell jedoch oft zu komplex: bei der Nutzung von VPNs, Cloud-Diensten und Infrastrukturen sowie einer Bring-Your-Own-Device-Policy ist nicht mehr klar, welchen Nutzer:innen und Geräten wo vertraut werden kann und wo nicht. Zudem ist der “Perimeter-Security” Ansatz sehr statisch, z. B. in der Form von Firewall-Regeln, die keine schnellen Änderungen zulassen, und damit eine zeitgemäße und agile Entwicklung von IT-Systemen behindern.

Im Zero-Trust Modell werden Nutzer:innen, Geräte und jeder Zugriff auf Netzwerkressourcen, Dienste und Applikationen grundsätzlich als potenziell unsicher angesehen. Es gilt der Grundsatz: “niemandem vertrauen, alles überprüfen”. Dies bedeutet, dass jeder Zugriff auf Netzwerkressourcen, Diensten und Applikationen authentifiziert und autorisiert werden muss, bevor er zugelassen wird. Ebenso sollte die Ausführung der Zugriffe dem Prinzip des least privilige folgen, und auf Anomalien hin überwacht werden.

Die genaue Umsetzung und Ausgestaltung des Zero-Trust-Modells spiegelt sich in der Zero-Trust-Architektur wider. Bestandteile dieser Architektur können sein: eine risikobasierte Authentifizierung unter zur Hilfenahme von Verhaltens- und Standortdaten, gegenseitige Authentifizierung der Dienste und Applikationen mittels mutual TLS, durchgängige Transportverschlüsselung, eine Mikrosegmentierung des Netzwerks, die Überprüfung des Endgerätezustands z. B. durch Remote Attestation, Mandatory-Access-Control Policies u. v. m.

Amerikanische und britische Cybersicherheitsbehörden empfehlen mittlerweile den Einsatz einer Zero-Trust-Architektur, und auch der Bund will zukünftig auf eine Zero-Trust-Architektur setzen.

Perimeter-Security und Zero-Trust ist in der Praxis keine binäre Unterscheidung, die konkret umgesetzte Security-Architektur liegt auf einem breiten Spektrum irgendwo dazwischen. Viele Zutaten einer Zero-Trust-Architektur lassen sich auch in einem Perimeter-Security-Modell nutzen. Und nicht in jedes Legacy-System lässt sich eine Zero-Trust-Architektur integrieren. Wie könnt ihr wissen, ob und wie weit ihr eine Zero-Trust-Architektur umgesetzt habt? Fragt euch einfach, welche eurer Systeme ihr ohne Security-Bedenken ins offene Internet stellen könntet. Für alle Systeme, auf die ihr mit Ja antworten könnt, habt ihr wahrscheinlich eine Zero-Trust-Architektur implementiert oder seid ihr ziemlich nah. Aber nur weil ihr es könntet, solltet ihr das nicht unbedingt tun - ihr wollt ja sicher nicht, dass jemand anderes euch zeigt, dass ihr die Frage falsch beantwortet habt.

Türchen Nummer 14: Advanced Persistent Threat

Ein Advanced Persistent Threat, kurz APT, ist ein langanhaltender und gezielter Angriff auf ein IT-System. Für APTs bedarf es erfahrene und mit reichlich Ressourcen ausgestattete Angreifer:innen. Ziel eines APTs ist es, Netzwerke und IT-Systeme zu infiltrieren, um diese für wirtschaftliche und militärische Zwecke auszuspionieren oder diese im Konfliktfall lahmzulegen oder gar zu zerstören.

Ein APT beginnt normalerweise mit einer sorgfältigen Recherche und Planung durch die Angreifer:innen. Diese versuchen, so viel wie möglich über das Ziel herauszufinden um so mögliche Schwachstellen zu identifizieren, die sie ausnutzen können. Bei der Infiltration kommen zum Teil auch Zero-Days zum Einsatz, die ihr vielleicht noch aus Folge 10 des letztjährigen Adventskalenders kennt, genauso wie ausgefeiltes Social-Engineering. Nachdem sich die Angreifer:innen erstmalig Zugang verschafft haben, installieren diese Backdoors, um sich permanenten Zugang zu verschaffen, falls der initiale Zugang entdeckt und geschlossen wird. Zudem versuchen sie in weitere Teile des Netzwerks und verbundene IT-Systeme vorzudringen. Dabei sind sie stets darauf bedacht, ihre Spuren zu verwischen, um nicht entdeckt zu werden. APTs erstrecken sich teils über mehrere Jahre, bevor sie entdeckt werden.

Die in APTs involvierten Angreifer:innen werden APT-Gruppen genannt. Um die für einen APT benötigten Ressourcen, angefangen von dem immensen Zeitaufwand bis hin zum Nachschub an wertvollen Zero-Days, die praktisch wertlos werden, wenn sie einmal bekannt geworden sind, aufbringen zu können, brauchen APT-Gruppen Unterstützung. Diese kommt normalerweise von staatlicher Seite, praktisch alle größeren Geheimdienste der Welt haben eigene APT-Gruppen oder unterstützen zumindest welche.

Die Namen von solchen APT-Gruppen habt ihr vielleicht schon mal gehört: APT28, Fancy Bear, Pawn Storm oder STRONTIUM. In diesem Fall sind das 4 verschiedene Namen für ein und dieselbe APT-Gruppe. Warum so viele Bezeichnungen fragt ihr euch? Zu einem, weil die verschiedenen IT-Security-Firmen unterschiedliche Namensschemata haben. Die einen nummerieren einfach durch, andere nutzen Elemente zur Benamung, wieder andere nutzen einen Tiernamen für das Herkunftsland der APT-Gruppe. Beispielsweise nutzt Crowdstrike für Russland zugeordnete APT-Gruppen Bear, für China zugeordnete APT-Gruppen Panda, als Teil des Namens. Zum anderen ist die Attribuierung von APTs extrem schwierig, sodass es sich manchmal erst im Nachhinein rausstellt, dass hinter verschiedenen APTs nicht unterschiedliche APT-Gruppen stehen, die schon jeweils eigene Namen bekommen haben, sondern ein und dieselbe APT-Gruppe.

In IT-Security-Kreisen gibt es ein geflügelte Wort, zurückgehend auf einen Ausspruch des ehemaligen FBI-Direktors James Comey: “Es gibt zwei Arten von Unternehmen: Die einen sind gehackt worden. Die anderen wissen es nur noch nicht.” - habt ihr euch auch schon mal gefragt, zu welcher von beiden Gruppen euer Unternehmen gehört?

36B

Türchen Nummer 13: Die Zutatenliste für eure Software – SBOM

Seit Solarwinds, log4shell & Co. sowie der “Executive Order on Improving the Nation’s Cybersecurity” der USA ist Supply-Chain-Security eines der aktuellen Top-Themen in der IT-Security. Eine zentrale Rolle spielt dabei die SBOM, die Software Bill of Materials. Software wird heutzutage nur selten komplett neu entwickelt. Normalerweise wird an vielen Stellen auf den riesigen Fundus an Open-Source-Bibliotheken zurückgegriffen. Das spart Unmengen an Geld und Entwicklungszeit, ist aber nicht ohne Risiken. Wenn in einer Bibliothek eine Sicherheitslücke entdeckt wird, sollte diese, je nach Schwere, möglichst zeitnah auf eine gefixte Version upgedatet werden. Dazu muss man natürlich zunächst einmal wissen, ob man eine verwundbare Version einer Software-Bibliothek in seiner Software nutzt. Was auf den ersten Blick trivial erscheinen mag, ist in der Realität alles andere als einfach. Die direkten Abhängigkeiten einer Software haben meistens selbst Abhängigkeiten, diese Abhängigkeiten der Abhängigkeiten haben natürlich auch wieder Abhängigkeiten, diese Abhängigkeiten haben auch wieder… Ihr seht, wo das hinführt: trotz wenigen direkten Abhängigkeiten hat man sich ruckzuck einen riesigen Rattenschwanz an indirekten Abhängigkeiten in die Software eingebaut. Die SBOM soll helfen, den Überblick zu behalten, welche Abhängigkeiten, in welcher Version, eine Software hat.

Ohne Tooling ist eine SBOM relativ wertlos. Wahrscheinlich ist es nicht mal zu schaffen, ohne Tooling eine vollständige SBOM zu erstellen. Einige Dependency-Manager können direkt SBOMs erstellen, bei anderen werden externe Tools oder Plug-ins benötigt. Die in der SBOM aufgeführten Komponenten können dann daraufhin geprüft werden, ob es bekannte Sicherheitslücken gibt. Auch dies können manche Dependency-Manager von Haus aus, andere brauche externes Tooling und Plug-ins. Das Erstellen und Prüfen der SBOM sollte am besten fester Bestandteil der Build-Pipeline sein.

Das Prüfen der SBOM innerhalb der Pipeline ist nur der erste Schritt. Es setzt nämlich voraus, dass erstens die Build-Pipeline regelmäßig läuft. Pipelines von Software, die sich im Maintainace-Modus befindet, laufen vlt. nur in größeren Intervallen. Innerhalb dieser Intervalle neu entdeckte Sicherheitslücken bleiben so erst einmal unerkannt, eventuell so lange, bis es zu spät ist. Für manche Software hat man gar keine Build-Pipeline, zum Beispiel weil sie hinzugekauft bzw. lizenziert ist. Deshalb sollten SBOMs idealerweise auch außerhalb der Build-Pipeline geprüft werden, und zwar kontinuierlich. Dazu bieten sich Systeme wie Dependency-Track von OWASP an.

Damit diese mit den verschiedenen Technologien und Dependency-Managern zurechtkommen, wäre ein einheitliches Format der SBOM wünschenswert. Wie so oft in der IT gibt es dabei konkurrierende Standards. Momentan sind zwei Formate dominierend: CycloneDX von der OWASP und SPDX, ein ISO-Standard, unter der Ägide der Linux-Foundation.

SBOMs automatisiert Erstellen und Prüfen ist in der Regel nicht besonders schwer. Falls ihr das noch nicht macht, sollte ihr das weit oben auf eure Aufgabenliste schreiben. Bis Weihnachten könnt ihr es schaffen, das in euren Pipelines zu integrieren.

616

Türchen Nummer 12: “Alles ist Eins. Außer der 0.” - Film Tipp

Letztes Jahr versteckten sich hinter Türchen 23 unsere Film- und Serien-Tipps zu Nerd- und Hacker-Kultur. An diesen hat sich auch in diesem Jahr nichts geändert. Ihr wollt Euch beim Schmuddelwetter die Zeit vertreiben oder habt keine Lust auf die immer gleichen Weihnachtsfilme? Dann hört doch nochmal rein. Einen Film von der Liste - “Alles ist Eins. Außer der 0.” - wollen wir Euch heute besonders empfehlen. Den könnt ihr nämlich heute Abend in der ARD sehen. Im Film geht es um die Frühzeit des Chaos Computer Club und einen seiner Gründer, Wau Holland.

Wegbereitend für die Gründung des Chaos Computer Club war das Treffen von “Komputerfrieks”, Komputer damals noch mit K geschrieben und Frieks mit ie, im September 1981 in den Reaktionsräumen der TAZ in Berlin. Initiiert wurde dieses Treffen durch die Einladung “TUWAT.TXT” abgedruckt in der TAZ, unterschrieben von Wau Holland und vier weiteren Technik-Aktivisten und Gründungsmitgliedern des CCC. Es ging um Themen wie “internationale Netzwerke”, “Kommunikationsrecht”, “Datenrecht”, also “wem gehören meine Daten”, “Copyright” und “Encryption”. Alles Themen, die auch heute hochaktuell sind und in der Rückschau, wir reden hier immerhin über das Jahr 1981, geradezu visionär sind.

Der Chaos Computer Club, und Personen aus dessen Dunstkreis, fiel in seiner Frühzeit durch spektakuläre Hacks auf – der BTX-Hack, der NASA-Hack und der KGB-Hack. Seit der Frühzeit des CCC, genauer seit 1984, erscheint auch die Zeitschrift des CCC: “Die Datenschleuder. Das wissenschaftliche Fachblatt für Datenreisende”. Im selben Jahr fand auch zum ersten Mal der Chaos Communication Congress statt, das jährliche Treffen der Hackerszene in Deutschland.

Heute ist der Chaos Computer Club einzigartig in der Welt. Mit über 8000 Mitgliedern ist er die größte Hacker:innenvereinigung Europas. Er kümmert sich um Themen wie Bildung, Informationssicherheit und Informationsfreiheit. Der CCC stellt regelmäßig Experten in politischen Ausschüssen, und zeigt immer wieder Schwachstellen und Fehlentwicklungen in aktuellen technischen Systemen auf. In sozialer, wirtschaftlicher und technischer Hinsicht. Zuletzt beim geplanten Austausch der Gematik-Konnektoren in Arztpraxen.

Schaut also rein, es lohnt sich: “Alles ist Eins. Außer der 0.” läuft heute Nacht um 0:20 in der ARD. Wenn ihr nicht dem Klischee des oder der nachtaktiven und lichtscheuen Hacker:in entsprecht, und ihr um diese Zeit bereits im Bett seid, dann könnt ihr den Film auch noch die nächsten 30 Tage in der Mediathek zu Eurer Wunschzeit schauen. Viel Vergnügen.

Türchen Nummer 11: What’s all the fuzz about?

Gestern hatten wir euch vorgestellt, was sich hinter dem Begriff Pen-Testing verbirgt. Auch heute, soll es ums Security-Testing gehen. Diesmal verraten wir euch, was es mit Fuzz-Testing, auch Fuzzing genannt, auf sich hat. Denn Tests gibt es meistens eher zu wenig als zu viel, gerade dann, wenn es ums Security-Testing geht.

Das Grundprinzip von Fuzzing ist simpel. Ein zu testendes Programm wird mit zufälligen Eingaben gefüttert, um daraufhin das Verhalten des Programms zu beobachten, mit dem Ziel potenzielle Sicherheitslücken zu identifizieren. Das klassische Verhalten, das eine Sicherheitslücke aufzeigt, ist der Absturz des Programms. Damit ist auf jeden Fall das Schutzziel der Verfügbarkeit aus der CIA-Triade gefährdet. Bei C und C++ Programmen ist der Absturz auch ein typisches Anzeichen für ein memory-safety issue, das oftmals für unautorisierte Code-Execution genutzt werden kann. Deswegen ist Fuzzing auch bei C und C++ Programmen besonders effektiv. Denn außer dem Absturz ist von außen wenig Verhalten beobachtbar, dass auf eine Sicherheitslücke hinweist. In der Praxis sind solche reinen Black-Box-Ansätze daher eher selten anzutreffen.

Auch wenn manuelles Fuzzing vorstellbar ist, sind Tools unverzichtbar, um gute Ergebnisse zu bekommen. Denn nur eine winzig kleine Menge aller möglichen Eingaben triggern überhaupt die potenziellen Sicherheitslücken. Programme und Frameworks fürs Fuzzing werden Fuzzer genannt. Diese bestehen idealtypisch aus drei Komponenten: dem Generator, der die zufälligen Eingaben generiert, dem Executor, der das Programm ausführt und mit den erzeugten Eingaben füttert, und dem Observer, der das Verhalten des Programms beobachtet. Ein Fuzzer kann, einmal gestartet, ohne weitere Eingriffe, automatisiert riesige Mengen von Eingabedaten testen.

Fuzzer können in verschiedenen Dimensionen unterschieden werden. Eine Dimension ist, wie sie die Eingabedaten generieren. Die eine Methode ist zufällig Bytefolgen zu erzeugen, die andere Methode ist, valide Eingaben zu mutieren. Gerade wenn es sich um komplexe Eingabedaten handelt, z. B. um Bildformate wie JPEG oder PNG, ist das Mutieren von validen Eingaben besonders effektiv. Wissen über die Struktur der Eingabe ist eine weitere Dimension. Hier wird unterschieden zwischen, „smart”, der Fuzzer kennt die Struktur der Eingabedaten, und „dumb”, der Fuzzer kennt die Struktur nicht. Eine dritte Dimension ist, inwieweit der Fuzzer die Interna des zu testenden Programms kennt. Vom reinen Black-Box-Testing, ohne Kenntnisse über die Interna, bis zu White-Box-Testing, bei dem das zu testende Programm zusätzlich instrumentiert wird. Die Instrumentierung wird einerseits genutzt, um Fehlersituationen zu erkennen, die von außen nicht beobachtet werden können, andererseits, um zu erkennen, welche Code-Pfade beim Fuzzing schon erreicht wurden und welche nicht. Die gewonnenen Informationen kann der Fuzzer auch nutzen, um bessere Eingaben zu generieren, indem der Observer, der die Informationen aus der Instrumentierung sammelt, diese zurück an den Generator gibt, umso eine Feedbackschleife aufzubauen.

Fuzzer laufen zum Teil mehrere Tage, daher sind sie nicht geeignet, bei jedem Commit und in jeder Pipeline zu laufen. Das sollte euch jedoch nicht abhalten, Fuzzing in eure Teststrategie aufzunehmen, auch wenn ihr kein C und C++ nutzt. Mit modernen Fuzzern wie Jazzer für Java, oder dem in der Go-Standardbibliothek vorhanden Fuzzer ist der Einstieg relativ leicht. Open-Source-Projekte können unter bestimmten Umständen auch am OSS-Fuzz Projekt von Google teilnehmen. Google stellt in diesem Projekt Ressourcen bereit, dass Open-Source-Projekte durchgehend gefuzzt werden können. So wurden schon zig Bugs in Open-Source-Projekten gefunden.

D62

Türchen Nummer 10: Pen-Testing

Wenn euer IT-System gehackt wurde und ihr das nicht so schlimm oder gar gut findet, dann habt ihr wahrscheinlich gerade einen Pen-Test hinter euch. Bei einem Pen-Test, kurz für Penetration-Testing, versuchen autorisierte Hacker:innen in ein IT-System einzudringen. Autorisiert bedeutet hierbei, dass die Hacker:innen explizit dazu beauftragt wurden, und dass das beauftragende Unternehmen auch die Hoheit über das zu testende System hat. Pen-Testing wird auch als „Ethical Hacking” bezeichnet. Häufig werden Pen-Tests im Rahmen eines Security-Audits durchgeführt. Das Ergebnis eines Pen-Tests ist normalerweise ein Report, in dem die entdeckten Sicherheitslücken dokumentiert werden. Oft werden in dem Bericht auch Tipps gegeben, wie die Lücken abgestellt werden können, genauso wie eine Einschätzung, wie schwerwiegend die einzelnen Lücken sind. Des Weiteren sollte der Report auch die Angriffe beschreiben, die im Rahmen des Pen-Testes durchgeführt wurden, jedoch nicht erfolgreich waren.

Ein Pen-Test gliedert sich in verschiedene Phasen. Bei Beauftragung wird der genaue Scope festlegt, also welche Systeme getestet werden sollen und welche nicht. Welche Angriffsmethoden sind ausgeschlossen? Erfolgt der Test von innen z. B. aus dem LAN oder von außen über die aus dem Internet erreichbaren Teilsysteme? Was ist der Umfang der Tests? Und vieles mehr. Darauf folgt normalerweise eine Erkundungsphase, in der die Pen-Tester:innen Informationen über das zu testende System zusammentragen. Zum Teil werden diese schon vom Auftraggeber bereitgestellt. Danach folgt typischerweise eine Phase, in der Tool-gestützt und automatisiert nach Schwachstellen gesucht wird. In der darauffolgenden Phase versuchen die Pen-Tester:innen, unter zur Hilfenahme der in den vorigen Phasen erworbenen Informationen, sich Zugang zum System zu verschaffen. Neben dem, doch recht einfachen Ausnutzen, der Lücken, die bei den automatisierten Scans gefunden wurden, wird in dieser Phase vorwiegend versucht, neue logische und technische Schwachstellen aufzudecken. Je nach Auftrag können weitere Phasen folgen, in denen die Pen-Tester:innen probieren, ausgehend von einem initial erfolgreichen Angriff, ob von dort weitere Angriffe möglich sind, und inwieweit es möglich ist, die Spuren zu verwischen, um zu zeigen, dass erfolgreiche Angriffe unentdeckt bleiben können.

Für genaue Definitionen und Ausgestaltungen der Phasen gibt es diverse Leitfäden und Standards. Beispielsweise von der OWASP oder auch vom BSI mit ihrem „Praxis-Leitfaden für IS-Penetrationstests”, welcher besondere Bedeutung in Deutschland hat, da viele deutsche Unternehmen und Behörden sich daran orientieren. Private PGP-Schlüssel oder Feuerlöscherempfehlungen findet ihr darin aber nicht.

Beim Pen-Testing kann grundsätzlich zwischen White- und Black-Box-Testing unterschieden werden, wobei es in der Praxis keine so strenge Trennung gibt, sondern viele Grautöne. Beim White-Box-Testing werden den Pen-Tester:innen auch interne Informationen, wie die Dokumentation des zu testenden Systems, Netzwerkpläne, Konfigurationen bis zum Source-Code zur Verfügung gestellt. Im Gegensatz dazu werden beim Black-Box-Testing keine Informationen bereitgestellt, die nicht ohnehin öffentlich verfügbar sind. Black-Box-Testing ist somit merklich näher an echten Angriffsszenarien dran, dabei jedoch deutlich weniger effektiv beim Aufdecken von Sicherheitslücken als White-Box-Testing, welches dafür auch die ganzen Interna nutzen kann. Letztlich ist es eine Frage der konkreten Zielsetzung und des Geldes, für welche Position auf dem Spektrum zwischen Black-Box oder White-Box-Testing man sich entscheidet.

Pen-Tests sind eigentlich unverzichtbar, in einigen Bereichen sind sie sogar gesetzlich vorgeschrieben. Sie sollten dabei nicht der einzige Baustein der IT-Security-Strategie sein. Der Pen-Test findet nämlich sehr spät im Software-Development-Lifecycle statt. Wie ihr bei Türchen 8 gelernt habt, sind Security-Probleme, die erst spät im Lifecycle entdeckt werden, oft auch die teuersten. Zudem zeigt der Pen-Test nur den Zustand zu einem ganz bestimmten Zeitpunkt auf, über die restliche Zeit sagt er nur wenig aus. Das ist ein Problem, wenn der Pen-Test jährlich stattfindet, was kein unüblicher Zyklus ist, das System sich aber im Wochenrhythmus ändert, was bei einem agilen Entwicklungsprozess auch nicht unüblich ist.

Neben dem Eindringen in IT-System gibt es auch noch eine besondere Art des Pen-Testing. Das Überwinden von physikalischen Schutzmaßnahmen, wie das Eindringen in gesicherte Gebäude, wie etwa Rechenzentren.

Zum Schluss ein paar Worte über die Fähigkeiten, die man als Pen-Tester:in mitbringen muss. Neben tiefen Verständnis in diversen Technologien braucht es auch eine ganz besondere Art von Kreativität, um Sicherheitslücken in den Systemen aufzuspüren. Für eine erfolgreiche Erkundungsphase sind auch gute Social-Engineering-Fähigkeiten von Vorteil. Das tägliche Arbeitsgerät von vielen Pen-Tester:innen verbarg sich übrigens im letzten Jahr hinter Türchen Nummer 3: Kali Linux.

Türchen Nummer 9: Namensverwirrung Nr. 2: "Raider heißt jetzt Twix – sonst ändert sich nix!” oder warum SSL heute TLS heißt

Hinter Türchen 6 haben wir schon die Namensverwirrung rund um OpenSSL und LibreSSL geklärt. Aber warum enden die beiden eigentlich auf SSL, nutzt man heutzutage nicht TLS? Und wo ist eigentlich der Unterschied zwischen SSL und TLS?

Als Mitte der Neunzigerjahre des letzten Jahrtausends das Internet begann sich auch in der breiten Masse durchzusetzen und der damit einsetzenden Kommerzialisierung des Internets, wurde der Bedarf nach einer verschlüsselten Datenübertragung immer größer. Wenn Zahlungsdaten einfach abgehört werden können, sind keine sicheren Transaktionen möglich, und E-Commerce oder Online-Banking, wie wir es heute kennen, sind ohne verschlüsselte Datenübertragung undenkbar.

Deshalb begann Netscape ab 1995 damit, ihren Browser Netscape Navigator mit dem Secure Socket Layer, kurz SSL, auszustatten. Der Netscape Navigator 1.1 wurde 1995 als erste Version mit SSL v2 ausgeliefert. SSL v1 wurde nie in einem Produkt veröffentlicht, da es diverse Sicherheitsprobleme hatte, und es bei einer Vorführung vor Marktstart innerhalb von 10 Minuten geknackt wurde. Auch SSL v2 war nicht ohne Probleme, sodass es schon nach wenigen Monaten von SSL v3 abgelöst wurde. Die Spezifikation von SSL v3 wurde auch später unter RFC6101 veröffentlicht. Microsoft hatte dem Private Communication Technology Protokoll, kurz PCT, in der kurzen Zeit zwischen SSL v2 und SSL v3 versucht, ihre berühmt-berüchtigte „embrace, extend and extinguish” Strategie anzuwenden. PCT war rückwärts kompatibel zu SSL v2, löste sogar einige der Sicherheitsprobleme von SSL v2, war aber nur für den Internet Explorer und die Internet Information Services, beides Produkte von Microsoft, verfügbar. PCT konnte sich jedoch nicht durchsetzen. Im Jahr 1996 konnten sich Netscape und Microsoft darauf einigen, dass sich die IETF zukünftig um die Weiterentwicklung des SSL-Protokolls kümmern sollte. Nach drei Jahren veröffentlichte die IETF dann in RFC 2246 die Spezifikation von TLS 1.0. Obwohl TLS 1.0 nur wenig Änderungen zu SSL v3 aufweist, und eigentlich SSL v3.1 ist, wurde der Name von Secure Socket Layer zu Transport Layer Security geändert. Einige Gerüchte besagen, dass Microsoft auf die Namensänderung bestanden hat, weil es nicht so aussehen sollte, als wenn sie das Protokoll von Netscape übernehmen würden. Andere Gerüchte besagen, dass die IETF nicht einfach das Protokoll eines Herstellers übernehmen könne, und mit der Namensänderung eine klare Abgrenzung gezeigt werden sollte. Letzteres konnte man ähnlich auch bei Speedy (geschrieben SPDY) und Quick (geschrieben QUIC) beobachten, beides Protokolle, die maßgeblich von Google entwickelt wurden, von der IETF aber als HTTP 2.0 und 3.0 spezifiziert wurden.

Was auch immer der Grund gewesen ist, die Namensänderung sorgt noch heute für Verwirrung. Heute sind TLS 1.2 und 1.3 aktuell, die Versionen 1.0 und 1.1 gelten bereits als veraltet, und SSL v3 wird fast nirgends mehr unterstützt. Trotzdem tragen OpenSSL und LibreSSL das SSL nicht nur im Namen, sondern auch die Funktionen und Objekte haben SSL als Präfix. Dabei hieß OpenSSL in den allerersten Commits für einen Tag sogar OpenTLS, allerdings war das noch vor einem offiziellen TLS 1.0. Und LibreSSL liefert sowohl eine libssl als auch eine libtls aus. Tools um TLS-Verbindungen zu prüfen heißen testssl.sh oder SSLyze. In den meisten Programmiersprachen und Bibliotheken öffnet man SSL-Verbindungen, auch wenn es sich um TLS-Verbindungen handelt.

Am einfachsten ist es wohl SSL und TLS einfach synonym zu verwenden, aber achtet in der Softwareentwicklung immer darauf, dass nur noch TLS 1.2 und TLS 1.3 zum Einsatz kommen.

Wenn ihr übrigens „SSL history” als Suchbegriff verwendet, kann es gut sein, dass ihr unter den Toptreffern auf Solid State Logic trefft, eine Firma für Audio Equipment. Die haben zwar nichts mit den SSL- oder TLS-Protokollen zu tun, stellen aber mit den Modellen SSL2 und SSL2+ zwei Audiointerfaces her, die Lisa und Christoph auch fürs Podcasting verwenden. Und kann es einen schöneren Namen für die Audiohardware eines IT-Security-Podcasts geben als SSL?

686

Türchen Nummer 8: Vom BSI empfohlene Sicherheitsmaßnahmen: Feuerlöscher

Vor genau einem Jahr haben wir euch an dieser Stelle berichtet, wie das Bundesamt für Sicherheit in der Informationstechnik, BSI, versehentlich einen privaten PGP-Schlüssel verschickt hat. Heute sprechen wir darüber, wieso das BSI einen Feuerlöscher empfiehlt.

Im IT-Grundschutz des BSI, der Unternehmen und Behörden dabei helfen soll, ihre IT abzusichern, wird u. a. empfohlen, einsatzbereite Feuerlöscher in ausreichender Menge parat zu haben. Was zunächst merkwürdig klingen mag, ist spätestens auf den zweiten Blick ziemlich logisch. Denn auch die Hardware-Infrastruktur gehört zu einem IT-System. Diese muss genauso geschützt werden wie die Software. Der IT-Grundschutz des BSI arbeitet mit einem Schichtenmodell und die Infrastruktur ist dabei eine von mehreren zu schützenden Schichten. Elementare Gefährdungen wie Wasser und Feuer werden dabei auch berücksichtigt, daher die Feuerlöscherempfehlung. Wie wichtig adäquate Brandschutzmaßnahmen sind, zeigte sich 2021, als ein Rechenzentrum des französischen Cloud-Anbieters OVH abgebrannt ist. In Folge waren mehr als dreieinhalb Millionen Websites mit über 450.000 Domains offline. Größere Datenmengen sind wegen fehlender off-site Backups für immer verloren gegangen. Ein Grund für das Abbrennen war wohl u. a. das Fehlen einer Löschanlage.

Bei der Sicherheit von Hardware dürfen wir aber nicht nur an Elementarschäden denken. Auch die aus Türchen 5 bekannten Hacking Gadgets sollten nicht in die Nähe unserer Hardware kommen. Dazu braucht es passende Zugangsregeln und Kontrollen. Dafür sorgen hoffentlich die Betreiber:innen der Rechenzentren, in denen eure Hardware steht.

Weniger oft wird an die tagtäglich benutze Hardware gedacht. Der Zugang zu einem Entwickler:innen-Rechner kann leicht schwerwiegender sein, als das versehentliche Verschicken eines privaten PGP-Schlüssels, da Entwickler:innen häufig privilegierte Zugänge zu IT-Systemen haben. Den Laptop nur mal kurz aus den Augen lassen kann oft schon ausreichen, um sich Zugang zu verschaffen. Ganz ohne physischen Zugriff auf eure Hardware kann euer Rechner ebenso durch Software übernommen werden. Viel zu häufig wird Software aus diversen Quellen ohne große Prüfung installiert. Gerade Entwickler:innen neigen dazu, sich schnell mal das neuste auf Reddit oder Hacker News gehypte Tool zu installieren. Supply-Chain-Angriffe, die auf Entwickler:innen Rechner zielen, sind freilich längst nicht mehr nur graue Theorie.

Zum Schluss noch ein paar wichtige Sicherheitstipps. Lasst euren Rechner nicht unnötig lange aus den Augen, verschlüsselt eure Festplatten, sperrt euren Rechner immer wenn ihr ihn gerade nicht benutzt, schließt keine auf der Straße gefundenen USB-Geräte an eure Rechner, installiert nicht einfach Software aus beliebigen Quellen, und ganz wichtig: bei Feuer erst das Gebäude verlassen, dann auf Twitter, TikTok, Instagramm & Co. posten - nicht umgekehrt.

Türchen Nummer 7: Shift-Left-Security, DevSecOps und Security Development Lifecycle

Shift-Left ist weder eine Aufforderung politischer Natur noch der Versuch den Straßenverkehr weltweit zu vereinheitlichen. Mit Shift-Left ist im allgemeinen gemeint, dass bestimmte Probleme und Themen schon in früheren Phasen eines Prozesses betrachtet werden. Der Begriff Shift-Left leitet sich davon ab, dass die aufeinanderfolgenden Phasen eines Prozesses in grafischen Abbildungen oft von links nach rechts dargestellt werden, die früheren Phasen also weiter links sind. Für die Security bedeutet dies, dass sich das Thema schon so früh wie möglich im Softwareentwicklungsprozess wiederfinden sollte, am besten bereits in der ersten Phase.

Lange Zeit war es üblich, Security gar nicht, oder erst dann zu bedenken, wenn der Softwareentwicklungsprozess fast oder ganz abgeschlossen war. Security-Lücken zu schließen kann so sehr kostspielig werden, wenn sie z. B. auf Fehler im Design oder in der Architektur zurückgehen. Je früher im Prozess Security-Probleme erkannt werden, desto preiswerter sind sie zu beheben. Microsoft musste das schmerzlich lernen. Mit zunehmender Verbreitung und Vernetzung von Computern in allen Lebensbereichen am Ende des letzten Jahrtausends wurden die Sicherheitslücken in den teilweise marktbeherrschenden Microsoft-Produkten immer mehr zum Problem. Nach Malware wie Code Red oder Loveletter, zu letzterem findet ihr hinter Türchen 21 aus dem letztjährigen Adventskalender mehr Informationen, die viele Millionen Computer infizierten und geschätzte Schäden im Milliardenbereich verursachten, wurde der Druck auf Microsoft so groß, dass der Microsoft Gründer Bill Gates persönlich eingeschritten ist. Am 15. Januar 2002 setze er in einer Mail mit dem Titel „Trusthworthy Computing”, die an alle Microsoft Mitarbeiter:innen ging, Security ganz nach oben auf die Prioritätenliste. Einer der wichtigsten Bausteine war und ist dabei der Security Development Lifecycle, kurz SDL. Dieser macht Security zum Teil von allen Phasen des Softwareentwicklungsprozesses, angefangen bei der Risikoanalyse, die ganz am Anfang des Prozesses steht, bis zum Incident Response ganz am Ende des Prozesses, wenn die Software sich bereits im Betrieb befindet. Auch heute noch wird bei Microsoft Software SDL-konform entwickelt. Der SDL wurde dabei immer wieder weiterentwickelt und an die aktuellen Gegebenheiten angepasst. Während er anfangs noch eher auf einen eher wasserfallartigen und langwierigen Softwareentwicklungsprozess zugeschnitten war, ist er heute auch an agile Entwicklungsprozesse angepasst. Und seine Wirkung hat er nicht verfehlt. Die Anzahl der Lücken in Microsoft Produkten ist infolge der Einführung des SDL merklich zurückgegangen. Zwar hat Microsoft zum Teil immer noch einen schlechten Ruf in Sachen Security, weil immer noch zahlreiche Lücken gefunden werden, aber das liegt eher daran, dass viele ihrer Codebasen, sehr groß und schon älter als der SDL sind. Dort schlummern deshalb weiterhin viele Sicherheitslücken. Zudem wird in den meisten dieser Codebasen auch noch C und C++ verwendet. Warum das ein Problem ist, habt ihr bei Türchen 3 gehört.

Heute hat der Begriff Shift-Left-Security eine noch umfassendere Bedeutung als die Verschiebung von Security in frühere Phasen des Softwareentwicklungsprozesses, sowie es der SDL vorgemacht hat, auch wenn damals noch niemand von Shift-Left-Security gesprochen hat. Vor allem die Automatisierung von Security, wie das Auffinden von Sicherheitslücken durch statische Codeanalyse oder das Scannen von Dependencies auf bekannte Sicherheitslücken, werden mit dem Begriff Shift-Left-Security kommuniziert. Genauso wie das Thema DevSecOps, bei dem um es das Aufbrechen von Team- und Verantwortlichkeitsgrenzen geht, sodass die Dev-, Ops- und Security-Teams gemeinsam an der Security arbeiten, und nicht hinter-, neben- oder gar gegeneinander.

Wie schaut es denn bei euch aus? Wann kümmert ihr euch um Security? Einmal im Jahr, wenn das Ergebnis des Pentest hereinkommt, der zig Sicherheitslücken aufgedeckt hat. Oder schreibt ihr eure Software schon immer SDL-konform, und die armen Pentester:innen können deswegen nur noch die letzten Sicherheitslückenkrümmel aufsammeln. Wahrscheinlich werdet ihr irgendwo dazwischen sein. Was bedeutet, dass es noch Verbesserungspotenzial gibt. Schaut doch einfach mal in den SDL rein, Infos darüber könnt ihr euch im Netz herunterladen. Das soll nicht heißen, dass ihr den SDL vollständig umsetzen müsst. Der ist nicht für alles und jeden geeignet, sondern zunächst für die Probleme von Microsoft. Gute Inspirationen dafür, wie ihr euren Softwareentwicklungsprozess besser und sicherer machen könnt, findet ihr dort aber bestimmt.

82D

Türchen Nummer 6: Namensverwirrung: OpenSSL, OpenSSH, OpenBSD, LibreSSL

Welcher der folgenden Begriffe passt nicht zu den anderen? OpenSSL, OpenSSH, OpenBSD, LibreSSL. Richtig, es ist OpenSSL. Ihr werdet euch jetzt bestimmt fragen: „Warum?”. LibreSSL hat doch den Präfix Libre während alle anderen Begriffe den Präfix Open haben. Stimmt, aber genauso könnte man sagen, dass der Suffix von OpenBSD mit „B” beginnt und alle anderen Suffixe mit „S”. Der entscheidende Unterschied versteckt sich auch nicht irgendwo in der Schreibweise, sondern liegt vielmehr in der Beziehung der Projekte untereinander. Der nicht passende Begriff ist OpenSSL.

Bevor wir auflösen, warum OpenSSL der nicht passende Begriff ist, schauen wir zunächst, was sich hinter den einzelnen Begriffen verbirgt.

OpenBSD ist, neben FreeBSD und NetBSD, eines der ersten unixartigen Betriebssysteme mit einer Open-Source-Lizenz. FreeBSD und NetBSD entstanden beide 1993. Beide basieren zum großen Teil auf 4.4BSD, einem, heute nicht mehr gepflegtem, Unix der Universität Berkeley. BSD steht dabei für Berkeley Software Distribution, davon leitet sich auch das BSD im Namen ab. OpenBSD wurde zwei Jahre später im Jahr 1995 von Theo de Raadt, einem der Gründer des NetBSD Projektes, nach einem Streit mit den anderen Gründern, von NetBSD abgespalten. Besonderes Augenmerk wirft OpenBSD auf das Thema Security. Auf der Homepage wird mit dem Slogan „Only two remote holes in the default install, in a heck of a long time!” geworben. Viele Security-Maßnahmen wurden früh oder sogar zuerst in OpenBSD integriert, z.B. Stack-Canarys oder W xor X (Write xor Execute). Deswegen, und wegen der liberalen Lizenz, findet sich OpenBSD oft in Security-Appliances.

Neben OpenBSD kümmert sich das Projekt auch um, die wohl populärste SSH-Implementierung, OpenSSH. Diese nutzt wiederum fast immer die kryptografischen Primitive von OpenSSL, ihrerseits die wohl populärste Bibliothek für Kryptografie und bekannteste TLS-Implementierung. Nur nicht unter OpenBSD, dort nutzt OpenSSH LibreSSL, einen Fork, den das OpenBSD-Projekt von OpenSSL abgespalten hat, in Folge von Heartbleed. Mehr über Heartbleed könnt ihr hinter dem zweiten Türchen unseres letztjährigen Adventskalenders hören. Und jetzt ist auch klar, warum OpenSSL nicht zu den anderen Begriffen passt. OpenBSD, OpenSSH und LibreSSL gehören zum selben Projekt, OpenSSL hingegen nicht. Gemeinsam ist jedoch allen, dass es wichtige, gar oft nicht wegzudenkende, Projekte in Sachen IT-Security sind. Kurz vor Schluss noch ein wenig Nerd-Party-Wissen für euch. Als Retourkutsche und Seitenhieb auf den Namen LibreSSL hatte sich das OpenSSL-Projekt eine Zeit lang die Domain libreSSH.org gesichert.

Von all diesen Begriffen nutzt ihr OpenSSL bestimmt, auch wenn ihr vielleicht gar nichts davon merkt, denn das steckt in unglaublich vielen Programmen. Wenn ihr SSH benutzt, verbirgt sich dort garantiert auch OpenSSH hinter. Auch falls ihr einen Client benutzt, dann läuft auf dem Server bestimmt OpenSSH. OpenBSD ist sicher auch mal einen Blick wert. Wer sich in Linux zurechtfindet, sollte auch im Umgang mit OpenBSD, nach kurzer Einarbeitung, wenig Probleme haben.

Türchen Nummer 5: Hacking Gadgets

Spionage-Thriller ist wohl bei vielen ein erster Gedanke, wenn sie Hacking Gadgets hören. Dabei sind viele Hacking Gadgets frei verkäuflich und so für jeden erhältlich. Rubber Ducky, MalDuino, USB Killer, Proxmark 3, USBNinja und viele andere sind schon für kleines Geld zu haben. Trotz eines relativ geringen Preises haben es die Hacking Gadgets in sich. Mit ihrer Hilfe können eine ganze Reihe von Angriffen ausgeführt werden. Vom Abhören von Tastatureingaben oder LAN-Verbindungen, über das Hacken von Wi-Fi-Netzen, Bluetooth-Verbindungen und anderen funkbasierten Technologie wie NFC, bis zum Einschleusen und Ausführen von Schadcode oder gar der physischen Beschädigung oder Zerstörung von Hardware. In jüngerer Vergangenheit haben äußerlich eher verspielte, aber nicht weniger mächtige, Varianten wie das Pwnagotchi oder der Flipper Zero für Aufmerksamkeit gesorgt.

Ihr fragt euch jetzt vielleicht, außer die Pentester:innen unter euch, die schon mehr als 25 Hacking Gadgets zu Hause herumliegen haben, warum ihr euch damit beschäftigen oder gar selbst ein Hacking Gadget besorgen solltet. Schließlich beabsichtigt ihr gar keine Angriffe auszuführen - das hoffen wir jedenfalls. Aber auch ohne Angriffsabsicht ist es lohnenswert, sich mit Hacking Gadgets zu beschäftigen und diese auch mal auszuprobieren. Denn ihr solltet wissen, wie ihr euch gegen Angriffe schützen könnt, die mit Hacking Gadgets möglich sind. Und dafür ist nichts besser geeignet, als die Perspektive zu wechseln, in die Rolle einer Angreifer:in zu schlüpfen, und deren Taktiken und Tools anzuwenden. Natürlich nur an eurer eigenen Hardware und Netzwerken, oder mit der expliziten Erlaubnis der Besitzer:in. Sonst könnt ihr gewaltigen Ärger bekommen, den Hackerparagrafen hatten wir euch letztes Jahr hinter dem siebten Türchen vorgestellt. Ach ja, ihr bekommt nicht nur ein besseres Verständnis, wie solche Angreife funktionieren, es macht oft auch einen Heidenspaß.

Nachdem wir das geklärt haben, bleibt noch die Frage, welche verschiedenen Hacking Gadgets gibt es denn? Grob kann man drei Kategorien unterscheiden: erstens Logger, die typischerweise zwischen einem Anschluss und einem Kabel gesteckt werden. Der Klassiker ist dabei der Keylogger, der Tastatureingaben abfängt. Daneben gibt es auch Screenlogger, die ein Videosignal, z. B. HDMI oder DisplayPort mitschneiden. Verbreitet sind auch Geräte, die den Traffic von kabelgebundenen Netzwerken ausleiten und mitschneiden können. Die zweite Kategorie wird oft als BadUSB bezeichnet. Über USB lassen sich heute alle möglichen Geräte anschließen. So kann sich ein Hacking Gadget zum Beispiel als Tastatur ausgeben und versuchen, die Eingabe von Befehlen zu simulieren, etwa das Öffnen einer Shell. In einer anderen Variante wird BadUSB dazu benutzt, die angegriffene Hardware zu beschädigen oder zu zerstören. Dazu gibt das Hacking Gadget einen gezielten Stromschlag ab, mit einer Spannung und Stromstärke, die weit über den USB-Spezifikationen liegen, was die Hardware beschädigt, wenn sie keine Schutzvorkehrungen vor Überspannungen hat. Die dritte Kategorie dient für Angriffe auf alle Arten von Funkverbindungen. Dafür wird ein Software-Defined-Radio benutzt, ein Funksender und Empfänger, bei dem die Frequenzen, sowie die Signal- und Protokollverarbeitung frei programmiert werden kann. Es gibt eine Reihe von Hacking Gadgets, die auch mehr als eine der Kategorien abdecken. Äußerlich lassen sich Hacking Gadgets oft nur schwer von legitimer Hardware unterscheiden. Vom Pwnagotchi und Flipper Zero mal abgesehen. Zum Beispiel sieht ein WIFI PINEAPPLE, ein Hacking Gadget für Wi-Fi-Netzwerke, genauso aus wie ein gewöhnlicher Wi-Fi-Router. Und BadUSB Gadgets gibt es heute auch in Form eines herkömmlichen USB-Kabels. Die nötige Elektronik ist so klein, dass sie im Stecker Platz findet.

Wenn ihr jetzt neugierig geworden seid, und auch mal ein Hacking Gadget ausprobieren wollt, dann könnt ihr ja eins auf euren Wunschzettel schreiben. Ihr müsst dann nur noch entscheiden, ob ihr mit dem Wunschzettel zum Weihnachtsmann, zu Q oder zum Online-Shop eures Vertrauens geht.

6C7

Türchen Nummer 4: CVSS - Das Commmon Vulnerability Scoring System

Ohne das reichhaltige Open-Source Ökosystem ist Softwareentwicklung heute kaum noch denkbar. Das bedeutet auch, dass man sich um die leider fast täglich aufploppenden Sicherheitslücken kümmern muss. Oft ist es nicht einfach einzuschätzen, wie schwer eine Sicherheitslücke ist, und ob sofortiges Handeln nötig ist.

Für Orientierung kann hier das Common Vulnerability Scoring System, kurz CVSS, sorgen. Damit werden Sicherheitslücken auf einer quantitativen Skala von null bis zehn abgebildet. Qualitativ können verschiedene Einstufungen der Schwere der Sicherheitslücke vorgenommen werden: von 0.1–3.9 LOW, 4.0–6.9 MEDIUM, 7.0–8.9 HIGH und 9.0–10.0 CRITICAL. Je nach Einstufung kann das Beheben der Lücke passend priorisiert werden.

Wie funktioniert das CVSS? Der CVSS Score berechnet sich durch die verschiedene Eigenschaften einer Sicherheitslücke. Zu diesen Eigenschaften gehören unter anderem die Komplexität des Angriffs, ob der Angriff über das Netzwerk funktioniert oder lokaler oder gar physischer Zugriff benötigt wird, sowie wie Verletzung der Schutzziele der CIA-Triade: Vertraulichkeit, Integrität und Verfügbarkeit. Aus diesen und weiteren Eigenschaft berechnet sich der CVSS Base Score. Beim Bekanntwerden von Sicherheitslücken wird dieser meistens direkt mitveröffentlicht. Zusätzlich gibt es noch den Temporal und den Environmental Score. Beim Temporal Score wird zusätzlich berücksichtigt, ob es sich nur um eine theoretische Lücke handelt oder welche Art von Exploits bereits bekannt sind, sowie das Vorhandensein von Patches oder Workarounds und die Glaubwürdigkeit der Veröffentlichung: von Unbekannt bis Bestätigt. Der Environmental Score lässt eine Anpassung an den eigenen Kontext zu. So macht es einen Unterschied, ob ein Angriff zwar über das Netzwerk möglich ist, das betroffene System aber gar nicht vom öffentlichen Internet erreichbar ist. Oder wenn durch die Sicherheitslücke die Vertraulichkeit der Daten gefährdet ist, das betroffene System jedoch gar keine vertraulichen Daten verarbeitet oder speichert. Das kann dazu führen, dass eine Lücke, die zwar im Allgemeinen als HIGH oder CRITICAL eingestuft wird, und normalerweise sofortiges Handeln erfordern würde, im eigenen System nur MEDIUM oder LOW ist, und somit eventuell erst im nächsten regulären Release gefixt werden muss. Die einzelnen Eigenschaften, die den Score ausmachen, werden auch in einem String-Vektor codiert: „AV:N/AC:H” steht z. B. für den Angriffsvektor Network und die Angriffskomplexität High. So ist es einfach nachvollziehbar, welche Eigenschaften die Lücke hat und wie der Score zustande gekommen ist.

Damit ihr die Formeln hinter dem CVSS nicht auswendig lernen und den Rechenschieber bemühen müsst, gibt es dafür Online-Rechner. Dort könnt ihr durch Zusammenklicken der Eigenschaften die jeweiligen Scores und den String-Vektor ermitteln. In vielen Sicherheitslücken-Datenbanken finden sich auch die CVSS-Scores zu den einzelnen Lücken. Hier müsst ihr aufpassen, mit welcher Version des CVSS der Score ermittelt wurde. Die Scores unterschiedlicher Versionen sind nicht direkt vergleichbar. Im CVSS Version 2.0 gab es beispielsweise nur die Einstufungen LOW, MEDIUM und HIGH. Aktuell ist die Version 3.1. Gepflegt und weiterentwickelt wird das CVSS von FIRST.Org, einer US non-profit Organisation, deren Ziel Hilfe für Incident Response Teams weltweit ist.

Wenn also beim nächsten Mal eine Sicherheitslücke mit einer Einstufung von HIGH oder CRITICAL in einer Eurer Dependencies auftaucht, dann nicht in Panik geraten. Erst mal den CVSS Score prüfen, dann den Environmental Score ermitteln. Wenn die Einstufung dann immer noch HIGH oder CRITICAL ist, den Fix oder Workaround, soweit vorhanden einspielen. Alternativ das System abschalten. Wenn das alles nicht geht, weil das System durchgehend laufen muss und ihr nicht Deployment-fähig seid und keinen Fix oder Workaround einspielen könnt, dann dürft ihr in Panik geraten.

46F

Türchen Nummer 3: NSA, Azure CTO und Christoph sind sich einig

Wenn sich die NSA und der CTO von Azure einig sind, dann könnte man denken, es geht um Backdoors, die für die NSA in Azure eingebaut werden sollen. Da aber auch Christoph zustimmt, der sich selbst mindestens zu einem Drittel der Aluhut-Fraktion zuordnet, muss es um etwas anderes gehen. Worüber sind sich also die NSA, der Azure CTO und Christoph einig? Darüber, dass C und C++ verschwinden müssen. Der Azure CTO hat das in einem Tweet formuliert, die NSA in einem Leitfaden und Christoph in einem Konferenzvortrag.

Aus welchem Grund sollen C und C++ verschwinden? Weil C und C++ von allen aktuell im breiten Einsatz befindlichen Programmiersprachen nicht memory-safe sind. Ein Großteil aller Sicherheitslücken, sowohl in der Vergangenheit als auch in der Gegenwart, resultieren aus memory-safety issues. So sind z. B. laut eigenen Angaben bei Microsoft Produkten und ebenso beim Chrome Browser von Google memory-safety issues für 70 % der Sicherheitslücken verantwortlich.

Lange Zeit gab es in bestimmten Anwendungsfällen, wie beispielsweise bei Betriebssystemen, Embedded-Systemen oder besonders performance-kritischen Anwendungen, keine Alternative zu C und C++. Mit keiner anderen Programmiersprache, die memory-safe ist, war eine ähnlich gute Performance-Charakteristik oder Low-Level Kontrolle erzielbar. Neuere Programmiersprachen, wie Nim, Go und Rust bieten allerdings vermehrt ernst zu nehmende Alternativen. Vor allem Rust sticht hierbei heraus: Memory-Safe, Performance vergleichbar mit C und C++ und interoperabel mit dem C Application Binary Interface. Dazu die Möglichkeit auch ohne libc dafür mit eingebetteten Assembler-Instruktionen denselben Grad von Low-Level Kontrolle wie C und C++ zu erreichen, der bei der Entwicklung von Betriebs- oder Embedded-Systemen nötig ist. Auch wenn in diesem Fall Rust die memory-safety nicht mehr garantieren kann, können die Stellen, wo das nötig ist, gut gekapselt werden. So hätte ein, noch fiktiver, Betriebssystem-Kernel in Rust nur ein paar Tausend Zeilen Code, die potenziell memory-safety issues haben können, von insgesamt 20–30 Millionen Zeilen Code, die ein moderner Kernel heutzutage umfasst.

Müssen jetzt Millionen oder gar Milliarden Zeilen C und C++ Code weggeworfen und in Rust neu geschrieben werden? Nein. C und C++ werden nicht von heute auf morgen verschwinden. Alter Code wird noch Jahre oder gar jahrzehntelang gepflegt werden müssen. Bei neuen Projekten sollte jedoch nicht mehr auf C und C++ gesetzt werden, sondern auf Alternativen wie Rust. Oder Go, wenn auch kleinere Abstriche bei Performance oder Low-Level Kontrolle gegenüber C und C++ gemacht werden können. Eine große Menge des modernen Cloud-Ökosystems, darunter so prominente Projekte wie Docker, Podman, Kubernetes und gVisor sind in Go geschrieben. Wären diese schon einige Jahre früher entwickelt worden, wären sie bestimmt in C oder C++ geschrieben. Bestehende C und C++ Projekte haben die Möglichkeit für einen sanften Übergang. Neue Funktionalitäten können mit Modulen und Bibliotheken, die in Rust geschrieben sind, implementiert werden. Nach und nach können auch bestehende Module und Bibliotheken ersetzt werden. So ist auch Rust selbst entstanden. Ein Mozilla Entwickler wollte eine sichere Alternative zu C++ entwickeln. Heute sind einige Teile des Firefox-Browsers in Rust implementiert, die ursprünglich C++ waren. Auch im Linux-Kernel ist es seit neustem möglich, Kernel-Module in Rust zu entwickeln.

Das größte Problem bei der Ablösung von C und C++ ist jedoch nicht technischer Natur. Vielmehr sind es Probleme sozialer, psychologischer, kultureller und politischer Art. Firmen und Personen, die stark in C und C++ investiert haben, haben erwartungsgemäß eher weniger Interesse an einer Ablösung, da das Investment auf Dauer weniger wert und die eigene Biografie infrage gestellt ist. Diese Hemmfaktoren wirken wahrscheinlich viel stärker als jegliche Defizite bei der Technik.

Achtet in Zukunft also auf memory-safety bei der Wahl der Programmiersprache. Für C und C++ gibt es eigentlich keinen Grund mehr.

Türchen Nummer 2: Cookies - Aber sicher

Heute ist der bundesweite Tag des Spekulatius, wie könnten wir diesen besser zelebrieren als mit einer Folge zu den Sicherheitsmechanismen, mit denen ihr eure Cookies schützen könnt.

Cookies laufen uns im Internet nicht nur zur Weihnachtszeit über den Weg - sie tummeln sich auf sehr vielen Webseiten und dienen im guten Fall dazu, Sessions zu identifizieren, Formulare abzusichern oder Nutzerpräferenzen abzuspeichern. Im schlechten Fall helfen sie, Nutzer und deren Verhalten zu tracken. In jedem Fall aber sollten Cookies abgesichert werden. Für die Absicherung können verschiedene Attribute genutzt werden.

Zum einen kann das „Secure“-Attribut gesetzt werden. Das sorgt dafür, dass der Browser den Cookie nur sicher, d.h. über eine verschlüsselte Verbindung, also via HTTPS, zurück an den Server schickt. Bei einer unverschlüsselten HTTP-Verbindung wird der Cookie nicht gesendet.

Ein weiteres Attribut ist „HttpOnly“. Das steuert nicht etwa, wie der Name vielleicht suggeriert, dass der Cookie nur noch über unverschlüsseltes HTTP übertragen wird. Also genau das Gegenteil vom „Secure”-Attribut. Vielmehr wird über das Attribut gesteuert, dass der Cookie nur bei HTTP-Requests sichtbar ist. Mittels JavaScript kann nicht mehr auf den Cookie zugegriffen werden. Der Cookie ist so zum Beispiel bei einem Cross-Site-Scripting Angriff geschützt.

Das letzte spannende, Security-relevante Attribut ist „SameSite“. Dieses spezifiziert, ob Cookies bei einem Cross-Site-Request gesendet werden, wie beispielsweise einem Seitenwechsel durch das Folgen eines Links, oder dem Laden von Ressourcen wie Bildern von einer anderen Webseite. Auch von einer anderen Website initiierte POST-Requests sind davon betroffen. Wenn dabei keine Cookies übertragen werden, werden viele Cross-Site-Request-Forgery Angriffe, kurz CSRF, wirksam verhindert, da diesen dann der passende Cookie mit Session bzw. Authorisierungsinformationen fehlt. Wird „SameSite“ auf den Wert „Strict“ gesetzt, werden Cookies nur noch übertragen, wenn Quelle und Ziel eines Requests die gleiche Seite sind. Manchmal ist es jedoch nötig, dass bei einem Seitenwechsel die Cookies trotzdem übertragen werden. Ansonsten funktionieren beispielsweise OAuth2/OpenID Connect-Flows oder viele Single-Sign-On Lösungen nicht mehr. Deswegen erlaubt „SameSite” auch den Wert „Lax“. Cookies werden dann zwar bei einem Seitenwechsel übertragen, bei anderen Arten von Cross-Site-Requests dagegen nicht. Als letzter Wert ist noch „None“ möglich. Der Cookie wird dann bei jedem Cross-Site-Request übertragen. Bevor es das „SameSite”-Attribut gab, war das das Standardverhalten. Mittlerweile ist „Lax” das Standardverhalten der meisten Browser, wenn „SameSite” nicht explizit gesetzt wird. „None” ist auch nur noch einstellbar, wenn gleichzeitig „Secure“ auf dem Cookie gesetzt ist.

Denkt immer daran: Cookies können vom Nutzer ausgelesen und manipuliert werden. Deshalb solltet ihr Cookies grundsätzlich mindestens mit einem Integritätsschutz wie einem HMAC oder einer Signatur versehen. Damit können Manipulationen erkannt und Requests mit manipulierten Cookies abgelehnt werden. Wenn zusätzlich der Inhalt der Cookies geheim bleiben soll, dann solltet ihr darüber hinaus die Cookies auch noch verschlüsseln.

Und nun, lasst euch nicht länger vom Spekulatius essen abhalten, wir sind morgen wieder für euch da.

727

Türchen Nummer 1: Hallo, liebe Hörer:innen

Hallo und herzlich willkommen zum INNOQ Security Podcast!

Heute ist der bundesweite Tag des Adventskalenders und auch wir sind mit dabei! Ihr habt gerade das erste Türchen unseres diesjährigen Adventskalenders geöffnet.

Auch in diesem Jahr wollen wir euch, liebe Hörer:innen, den Advent mit Wissen zu Security versüßen. Wir liefern wieder jede Menge Short-Facts, einen grandiosen Filmtipp für einen kalten Winterabend und knüpfen außerdem an das ein oder andere Türchen aus dem letzten Jahr an.

Doch wer sind “wir” überhaupt? Dieses Jahr sind diese helfenden Elfen mit von der Partie: Stefanie, Sonja, Sonja, Christoph, Ute, Lucas, Anja, Kevin, Robert und Lisa

Am 24. warten keine Geschenke auf euch, sondern eine harte Nuss. Wenn ihr es schafft, diese zu knacken, habt ihr die Chance auf einen fulminanten Gewinn!

Ein Tipp vorab: Lauscht jede Folge aufmerksam bis zum Ende.

Wir freuen uns, dass ihr wieder den Weg zu uns gefunden habt und den Advent mit uns verbringen wollt! Genießt mit uns die Vorweihnachtszeit und klopft jeden Tag an unsere Türchen.

Der Security-Adventskalender 2022

24 Türchen: 24 Folgen

Shownotes & Links

Türchen Nummer 25: Des Rätsels Lösung

Türchen Nummer 24: Das Weihnachtsrätsel

Türchen Nummer 23: Deepfakes

Türchen Nummer 22: Hardening

Türchen Nummer 21: Darkweb, Darknet und das Tor-Netzwerk

Türchen Nummer 20: Capture-the-Flag

Türchen Nummer 19: Namensverwirrung Nummer 3 – Cross-Site-Scripting

Türchen Nummer 18: IT-Security Farbenlehre, Teil II – Black, Grey und White Hat

Türchen Nummer 17: log4shell – ein Jahr danach

Türchen Nummer 16: IT-Security Farbenlehre – Red vs. Blue

Türchen Nummer 15: Zero-Trust

Türchen Nummer 14: Advanced Persistent Threat

Türchen Nummer 13: Die Zutatenliste für eure Software – SBOM

Türchen Nummer 12: “Alles ist Eins. Außer der 0.” - Film Tipp

Türchen Nummer 11: What’s all the fuzz about?

Türchen Nummer 10: Pen-Testing

Türchen Nummer 9: Namensverwirrung Nr. 2: "Raider heißt jetzt Twix – sonst ändert sich nix!” oder warum SSL heute TLS heißt

Türchen Nummer 8: Vom BSI empfohlene Sicherheitsmaßnahmen: Feuerlöscher

Türchen Nummer 7: Shift-Left-Security, DevSecOps und Security Development Lifecycle

Türchen Nummer 6: Namensverwirrung: OpenSSL, OpenSSH, OpenBSD, LibreSSL

Türchen Nummer 5: Hacking Gadgets

Türchen Nummer 4: CVSS - Das Commmon Vulnerability Scoring System

Türchen Nummer 3: NSA, Azure CTO und Christoph sind sich einig

Türchen #2: Cookies - Aber sicher

Türchen #1: Hallo, liebe Hörer:innen

Die helfenden Elfen 2022

Transkript

TAGS