 Und zwar, ich halte euch heute am Vortrag über, wie ich die Regierung gehackt habe. Das ist absichtlich super Click-Batey, aber es ist nicht direkt falsch. Also wer bin ich? Ich bin der Markus. Ich komme aus Oberösterreich, wie es dir vielleicht an meinem Dialekt erkennt. Sie ist Studierender J.K.U. Ich arbeite bei Catalyst, das ist so Programmierfirma. Und ich bin beim CTF Team Siegfleug von Linz. Wenn sie aus Linz hat, schaut es vielleicht einmal vorbei. Und ich bin Pentester Programmierer, Security Manager und AI Programmierer in einem AI-Projekt. Und sprachlich wird das Ganze irgendwo zwischen Österreichisch und Englisch ablaufen, wie in jedem technischen Tag. Also, HMMI haben wir schon hinter uns gebracht. Dann, wie ich die Regierung gehackt habe, wie ich meine Firma gehackt habe. Und dann kommt noch was für Spannenderes. Also, nicht weglaufen, man sich jetzt denkt, das ist blöd. Dann fangen wir mal an. Wir haben ein Firmen-Chat. Wir verwenden mittlerweile K-Skype mehr. Aber es war Skype. Unsere Regierung hat im Prinzip Dudel nachgebaut, also so eine Terminfindung, Abstimmungsthingen. Und das hat wer von uns ganz witzig gefunden und hat das in unserem Spaß-Skype gepostet. So, schau mal, TerminogVAT, existiert noch immer. Witzige GVAT-Domain. Da habe ich mir gedacht, probieren wir mal ein paar Sachen aus. Da habe ich dann einmal gepostet. Hey, cool. Schauen wir sie mal an. Und vom Zeitverlauf, man kann es, glaube ich, nicht so gut lesen. Aber innerhalb von in etwa einer halben Stunde habe ich Cross-Sites-Gripting gehabt und über Stund gebracht, dass ich Rick Astley Never Gonna Give You Up Auto-Playing einbauen. Also es war schwerer, wenn zu Rick Rollen als das Ding zu hacken. Also, dann interaktive Frage. Wer wird quicker? This bad boy als Name oder ein Dudel von unserer Regierung? Ja, die Antwort ist one. Und jetzt kommt die Frage, wie lange hat es gedauert, der ganze Loop von das Reporten und dann auf der anderen Seite analysieren und fixen. Und das machen wir jetzt wirklich einmal interaktiv. Es hebt jetzt jeder die Hand, der glaubt, klar, noch ist drei Stunden. Okay? Für das Recording, ich sehe Nullhände. Irgendwer, der glaubt, das hat unter drei Tage gedauert. Für das Recording, Nullhände, unter drei Wochen. Und wer glaubt, dass das Nullhimer geht? Ja, also für das Recording in etwa alle Hände waren beim vierten Punkt. Also bei es geht Nullhimer. Und ha ha, fast. Es ist noch unter drei Stunden gefixt gewesen. Ich weiß nicht, ob es vielleicht nur kürzer war, weil ich habe erst nach drei Stunden nachgeschaut. Und der Witz war, dass das nicht direkt von unserer Regierung selber, sondern von einem Subcontractor gemacht worden ist. Und das ist auch für Pentesting eine ganz nette Idee, wenn man sich nicht den sucht, der es betreibt, sondern den, der es wirklich gemacht hat. Wann sei es ein sinnvolles Impressum hat, finden wir den eigentlich. Und die waren super nett und haben das super schnell gefixt. Und ich habe denen gesagt, ich bin bei einer Software-Entwicklungsfirma, wo jetzt vielleicht das mal ich helfen, so, auftragsmäßig, für Gott. Haben es gesagt, nein, ist schon gefixt. Danke fürs Reporten, voll cool von euch. Also es sind nicht immer diese Firmen, wo ich euch verklagen, Horror-Stories, ab und zu rennt alles einfach super. Und dann habe ich das ein bisschen in der Firma erzählt. Wir haben unseren Spaß gehabt, ha ha ha, die machen voll schlechte Software. Wir sind viel cooler. Bei uns gibt es das natürlich nie. Wir sind eine Qualitäts-Software-Firma. Und wir haben im Prinzip so ein Firmen-Internis-Content-Management-System, das wir auch vertreiben. Und da habe ich einen Info-Eintrag über eine Konferenz in St. Pölten geschrieben. Und da oben sagt, Kollegin, habe ich dann gefragt, hey, wie kannst du da im Text Links machen? Bis ich drauf komme, bin ich ja okay. Eigentlich gibt es in diesem Editor gar kein Button für Links. Ich habe da einfach Markdown geschrieben. Das ist das eigentlich beliebteste Text-Format-Dingsy, das man irgendwie in Form verwendet oder auf WordPress. Und ich habe das irgendwie intuitiv geschrieben und das hat funktioniert. Bin ich drauf gekommen, das ist eigentlich kein Intended-Feature. Eigentlich wollen wir davon nur Bold und Italic verwenden. Dafür gibt es Buttons, aber nicht für Links. Da habe ich dann bemerkt, okay, probieren wir mal aus. Vielleicht gehen da ja auch andere Links, als nur Links of Websites. Und wahrscheinlich ist es auch nicht getestet, wenn es kein Button dafür gibt. Ja. Man kann meinen wirklich schlimmen Exploit sogar noch im Hintergrund sagen, man kann ja Links auf das Schema JavaScript machen und dann halt auch beliebigen Code ausführen. Gibt dann natürlich auch noch einen netten Proof of Concept, wo man von seinem eigenen Profil, alle Files, die man hoch klaren hat, dann zerst einmal wieder crawled und dann irgendwann einen anderen Server schickt. Das wäre so ein Beispiel-Szenario. Und warum erzähle ich euch das alles? Bis jetzt war das eigentlich alles nur ein Köder für den eigentlichen Teil von meinem Talk. Wir entwickeln alle Software oder sehr viele von uns und Kana ist perfekt und wir machen alle Fehler. Und auch wenn so Stunt-Tacking-Talks ganz cool sind, würde ich gerne am euren Talk darüber halten, wie kämpen wir eventuell zumindest die dümmsten Fehler vermeiden, dass sie Pent-Tester zumindest nicht in die ersten 10 Minuten von einem Pent-Tester gefreien, dass sie schon drei Sachen gefunden haben, wie Test-Test oder ein Username mit Cross-Site-Scripting. Und ja, ihr macht es auch Fehler, das hat es nicht so arrogant. Das wirkt man in sehr viel dieser Stunt-Tacking-Talks. Gerade beim CCC. Ich mache genauso Fehler. Ich habe auch in Software, die ich entwickelt habe, haben mir Leute wirklich peinliche Sachen gesagt. Man ist oft betriebsblind bei eigenem Code. Und eventuell, wenn sie Software ausliefert, die dann öffentlich im Internet zugänglich ist und Benutzerdaten beinhaltet, vielleicht auch externe Firmen oder zumindest andere Leute aus anderen Teams, fragen, hey, wie wäre es mit einem echten Pent-Test? Und wenn es nur eine Stunde ist, gibt es natürlich jetzt Catalysts, Fazer, Sec-Konsult, SPA Research und eine Million andere Firmen, wenn ihr eventuell die Kompetenzen dazu nicht in der eigenen Firma habt. Aber ich kann irgendein Form von Sicherheitstesting, Form ausliefern, nur empfehlen. Kann sich natürlich nicht jeder leisten. Vielleicht findet ihr auf dem Kongress irgend wem, der euch hilft, wenn ihr irgendein cooles Open-Source-Projekt macht. Es sitzen da draußen einen Haufen gescheite Leute herum, die euch vielleicht auch so helfen für Mathe oder Marikistenbier. Wenn ihr was für die Regierung macht, ist grundsätzlich, ob am gewissen Punkt von Bürgerdaten auch das BMI teilweise zuständig, ist immer ein bisschen kompliziert mit der Zuständigkeit oder eure lokalen Hackerspace-Gruppen fast jede mittelgroße Stadt hat so eine, würde ich vielleicht auch für ein paar Kisten Mathe helfen, falls ihr euch jetzt denkt, Security-Consulting for a day, das kann ich mir nicht leisten, aber wir kennen auch nicht einfach Daten im Internet haben, die dann relativ leicht aushebelbar sind. Und jetzt kommen wir zum eigentlichen Meet von meinem Talk und zwar, was kann man machen? Wie kriegt man seine Programme sicherer? Dann fangen wir einmal mit Thermologie. Also, was sollte man in etwa wissen an Wörter, dass man überhaupt über das Thema reden kann, wenn man keine professionelle Sicherheitsausbildung an einer Universität oder ähnliches hat? Gibt es ein paar wichtige Kernkonzepte? Dann gibt es das Mindset von einem Pentester oder vom Testing im Allgemeinen. Dann gibt es wichtige Design-Guidelines, die sichere Software entwickelt. Dann zu den Themen Frameworks und Programmiersprachen, weil es da sehr viel Diskussion gibt. Dann gibt es klassische Fehler, die man immer und immer und immer wiedersehrt. Man versucht, ein Pentester die billigsten Fehler zu exploiten. Es ist irgendwie tragisch, dass SQL-Injections im Jahr 2019 immer funktionieren. Und am Schluss praktische Beispiele. Und ganz am Schluss noch ein paar Exploits, die ihr vielleicht einfach einmal gegen und exploits sind anzeilige Stücke code. Das ihr einfach gegen eure Textfelder oder Text-Files schmeißen könnt in eurer eigenen Software, weil so komplizierte Dinge machen wir das Pentester meistens gar nicht. Wir finden die spaßigen Dinge teilweise nicht einmal mit super Sophisticated Diariescript, sondern mit, wir schreiben da Alert One in der Textbox eine oder Templating-Sachen. Also dann, Terminologie, eigentlich das Wichtigste sind die drei Säulen, der Sicherheit, Confidentiality, Integrity und Availability. Also eurer Site ist eigentlich auch nicht sicher, war nicht das von meinem Zuhause, Internetanschluss mit 50 Ambit und ihr seid auf Gigabit angebunden, wann ich euch an Server ditoßen kann, weil ihr einfach so ineffizient programmiert habt, dass ihr euch da einen Suchernfragen schickt und euer Site nicht mehr erreichbar ist. Das ist grundsätzlich eigentlich auch ein Security-Flaw. Natürlich Integrity-Daten verändern, überhaupt Daten, die zu einem anderen eigentlich kehren, ist natürlich ein Problem. Und Confidentiality, wenn ich den Traffic von anderen User mitlesen kann oder irgendwie Informationen von anderen User kriegen, ist natürlich auch ein Problem. Aber meiner Meinung nach, das am öftersten vergessen ist Availability. Ja, und es gibt mehrere Angriffsvektoren, die relativ typisch sind und da kann man eigentlich bei die meisten Anwendungen heutzutage sagen, irgendwie Server-Client oft Web-Based. Und es gibt eben Local-File-Inclusion und Remote-File-Inclusion, gerade in Java-Based oder Python-Based oder PRP-Based Sachen gibt es doch nur öfter, dass man auf irgendein Ort lokale oder sogar Remote-Files einbinden kann, weil das einfach Sprachfeatures sind, also in Java weniger. Aber im Python oder PRP ist das eigentlich ein Sprachfeature, das bei default in einige Web-Server-Deployments enabled ist und wenn man halt aus dem Kapitel 2.0 Sachen macht, dann kann das schon mal passieren und wenn man dann einmal Local-File-Inclusion oder Remote-File-Inclusion hat, also Code auf einem anderen Computer ausführen kann, ist man am Anfang halt noch mit relativ niedrige Privilegien und kann üblicherweise nur im Rahmen dieser Anwendung irgendwie kaputt machen. Es gibt eben einerseits dann, dass man einmal mit diesen niedrigen Privilegien alles extrahiert, aber auch Privilegiascalation, also dass man dann eventuell aus einem Docker oder einem VM ausbricht, da gibt es immer wieder einmal überhaupt man sich nicht updated, mittelschwierige Sachen. Das sind eigentlich all die komplizierten Terminologiewörter, die verwenden werden. Ich hoffe, ihr habt das akzeptabel erklärt. Ja, dann meinst du, eigentlich sind Pentestor superfall, wir gängern großteils auf Low-Hanging-Fruit. Low-Hanging-Fruit ist einfach Script-Alert-One zum Beispiel jetzt und ich habe vorher auch oder im Titel eigentlich Hacking, einfach einmal so in den Raum geworfen, aber eigentlich ist ein Hack am ehesten erklärbar mit dem Konzept von einer quick and dirty Lösung, die auch funktioniert, so vergleichbar mit Lifehacks. Also du machst irgendwas anders, als es intended ist, aber es funktioniert auch super. Und von dem kommt eigentlich Hacking oder auch von du bastelst irgendwas und du löst das irgendwie drei Kabel zusammen und dann funktioniert das Ding. Das ist auch ein Hack. Eigentlich hat Hacking nicht zwingend irgendwas mit Securities und auch. Und es ist immer wichtig, die Idee von einem Hack ist, es geht, es wurscht wie. Beim Pentest ist es eigentlich auch egal, wie du jetzt die Sicherheit auskabelt hast und das Wichtigste an einem Pentest ist, ich muss nur Anfehler finden, ihr als Anwendungsentwickler muss alles absichern. Das heißt, eigentlich hat der Pentester meistens einfacher, weil es 1 Mio. verschiedene Orten von Input in euch ein Programm gibt. Also wie irgendwie was daherkommt, was euch in unerwartetes Verhalten führen kann. Oder teilweise eigentlich normales default Verhalten, das eigentlich in dem Kontext, wie es ihr verwendet, nicht ganz hübsch ist. Und so ein Beispiel, sondern natürlich Logs oder Fehlermördungen oder West Java Base, schmeißt einfach mal einen ganzen Stacktrace entgegen. Und von so einem Stacktrace kannst du üblicherweise auch schon sehr, sehr viel ausserlesen, alleinischerweise die Line-Numbers in die verschiedenen Versionen von Imports verschieden sind. Man kann aus solcher Dinge extrem viel rausanalysieren, ist auch in der Security-Forschung ein riesiges Ding und ein der Software-Forschung eigentlich ganz groß. Als Tester muss man auch immer das Konzept von Testcoverage denken, wer Pentest ist, trotzdem ein normaler Tester. Und man macht es eigentlich immer auf irgendwelche Features, wo man sich denkt, das verwendet ja keiner. Das ist irgendwo der hinterletzte Button im dritt hinterletzten Menü. Weil das ist wahrscheinlich nicht getestet, das ist wahrscheinlich nicht abgesichert. Da gibt es dann oft irgendwelche Kompatibilitätsfeatures, die nicht mehr wirklich gewartet werden oder irgendwelche Developer-Features, die nur exposed sind, weil irgendwie keiner daran dacht hat, dass man das On-Deployment vielleicht abdraht. Und das ist im Prinzip das Mindset, das IS-Pen-Tester und auch andere Pentester. Und dann gibt es die Software-Design-Prinzipien, die eigentlich von OWASP, also einer offenen Security- Community kommen und es sind leider Sachen, die man nicht super übersetzen kann und die Wert eigentlich einmal drauf eingehen. Aber es sind Sachen, die ich schon öfter gesagt habe, Attack-Surface minimieren. Also stöhn' nix ins Internet, was dort nicht sein muss, natürlich. Gibt keine Fehler aus, die dort nicht hinkern. Das geht und normalen User nichts an, was das Stacktrace ist. Security-Faults ist bei manchen Programmiersprachen weniger gut, dass eben zum Beispiel wenn man's nicht richtig einstört, dann kann man ja komplett das Stacktrace und irgendwelche Debug-Informationen aus einem Web-Server ausserfallen. Principle of Least Privilege und Defense in Depth sind eher Administrationsthemen als Software-Entwicklungsthemen. Fail securely natürlich ist auch was, was meistens an der Sprache kommt. Don't Trust Services und Services sind eigentlich alles, was irgendwie von externen kommt. Teilweise auch, was der User oft kriegt, er hat teilweise Sachen über ein User von externen Services und der User hat da die Kontrolle. Separation of duties ist jetzt da wieder eher administrativer Geschichte, aber es bleibt leider oft ein Programmiererhänger. Security by securities natürliche, dumme Idee ist ja aber trotzdem noch relativ oft und keep security simple oder eigentlich keep it simple stupid ist ein sehr beliebtes Thema in dem ganzen Bereich weil es ist für mich als Pentester zwar schwer dein Obskuren zusammenkommt zu lesen, aber wenn du dann draufkommst eigentlich hast du es nur so obskuren kompliziert gemacht weil du um irgendeiner Security-Konzepte herum gearbeitet hast dann find man das mit der Bissi-Erfahrung meistens auch ganz gut ausser und eigentlich ist es nur schrecklich zu mentänen als Sicherheits, als normaler Entwickler wenn man in einem Team entwickelt und Teamkollegen hat die eventuell etwas obskure Security-Konzepte verwenden und das zu mentänen ist es tut euch mehr weh als es euch hilft, da macht es lieber gar keine Security statt Obscure Security die da im Feld und man weiß nicht worum und wenn euch irgendwer Fehler reportet sollte man es natürlich korrekt fixen zum Beispiel wenn euch wer script alert one einischibt könnt ihr nicht am Filter machen wir verbieten jetzt script alert one solltet ihr das schaue jegliche Ausführungen von Scripts verbieten was gar nicht so leicht ist und dann kommen wir zu Frameworks einerseits würde ich sagen wir solltet auf jeden Fall Frameworks verwenden, gerade im Web-Bereich weil nervt wie eigentlich immer wieder die selben Funktionalitäten entwickeln, so da Klassiker sind natürlich Templating wir haben etwas eingeben und das würde ich jetzt wieder ausgeben aber mein Ausgabe ist auf einer Website das heißt das solltet eigentlich KHTML sein weil sonst habe ich gleich eine Security-Lücke das solltet richtig formatiert sein und das solltet eventuell schon validity-checking machen Dinge die du in jedem Web-Framework hast Krypto, du solltet niemals das ist Lection number one in jeden Kryptografiekurs ihr habt euch jetzt im wichtigen Teil das andere ist sehr unspannend import Krypto einfach und eigentlich diese ganzen Standard-Sachen solltet man niemals selber schreiben weil immer wenn ich da eine eigene Implementierung sehe, das ist auch bei CTFs ein Standardding ist irgendein dummer Fehler drinnen, weil einfach Leid die diese Frameworks bauen die verwenden Tage und Wochen und denken da 10 mal drüber immer einfach selber meistens nicht so gut zusammen und außerdem verschwendet man haften Zeit, wenn man boilerplate-Framework-Templating blödsinnprogrammiert und ja, es hat nicht arrogant und glaubt es hat besser darin ein Framework zu schreiben und es gibt genug Frameworks es gibt wirklich genug Frameworks in jeder Sprache für alles was man braucht und dann andererseits verwenden es bloß keine Frameworks Frameworks haben immer eine Hinten-Complexity das heißt, sie machen oft Dinge die sie ihr nicht erwartet und wenn sie ein Framework verwendet dann solltet ihr eventuell die Doku lesen dann solltet ihr wenn die 5000 Default-Parameter haben eventuell mal anschauen ob die sicher und gut sind je größer und beliebter das Framework ist umso besser sind eure Chancen dass die Default-Parameter schon mal auf eine minimale, sichere, kluge Option getrimmt sind bei irgendeinem uralt-shower-serverfasers das mit Vue.js 2.0 zusammenarbeitet wo vielleicht drei Developers dran sitzen kann es durchaus sein, dass Dinge nicht unbedingt optimiert sind und daher solltet man die Menge am Frameworks die man verwendet minimieren, weil man sie mit jedem Framework das man importiert zumindest so minimal mit meiner Meinung nach und zum Beispiel haben wir vorher ja gehabt wir haben ein Framework gehabt für dieses Markdown-Passing und das war API Endpoint da schickst du Text hin der Markdown ist und dann fällt da hinten hübsches HTML dass man in einer Seite einbinden kann außer das hat halt einfach keine Validation von links wo die jetzt hingängern und das script als Schema gängern weil da hat vermutlich einfach wer von dieser speziellen Framework-Funktion die doko nachkläßen dann gibt es auch noch so klassische Dinge die immer wieder zu witzige Corner-Cases führen wie natürlich Schemas also neben File und Java Script gibt es ja gerade bei PAP nur 1 Million Sachen dazu kommen wir später noch oder Unicode verursacht auch da 1 Million Probleme überhaupt wenn euch ein Endpoint was verarbeitet was nicht Unicode ist oder was man sagen kann das kommt dann aber zurück und wird als Show Unicode eingebunden gibt es 1 Million Spaßigkeiten überhaupt in der C Word natürlich mit Null Termination das sind aber eher schon Details aber es ist wichtig wann sie ein Framework verwendet lässt sie doko dann ist es so clickbaity und kritisch zu behaupten irgendein Sprach ist besser als andere aber ich trau mich ganz mutig zu sagen die meisten Sprachen haben irgendein Zweck ich hab das Büttel daneben nicht selber gemacht aber ich finde bei sehr viel Ding ist es relativ passend also gerade mit Assembly kannst du super präzise genau dies machen was du wirst wenn du nicht weißt was du tust kannst du sehr schnell sehr wedo und gerade bei High Level Projekte wie Web Projekte ist es vielleicht ganz nett wenn man typisierte Sprachen hat oder Sprachen die zumindest das Konzept von Typen und von Ähnlichen haben für die Zuschauer es wird gerade gemummelt über dieses Bild und ja es ist immer zu bedenken beim Sprachdesign ist dieser Sprache für den Zweck für die es verwenden wird gedacht zum Beispiel wenn ich einen Treiber mache werde ich vielleicht nicht Java verwenden wiederum wenn ich ein Website mache ist es vielleicht Assembly und C so eine mittelgute Idee würde ich mal sagen es gibt auch Dinge die eher universell sind zum Beispiel Pfeifen wenn man zu Low Level und wenn man nicht zu viel Multi-Frading Performance braucht kann ich Pfeifen gerade für Anfänger eigentlich sehr empfehlen wobei wenn man bis die Schmerzresistenten das CEC++ auch ganz witzig ist wenn man aus der Mathematik kommt das Haskell vielleicht ganz witzig ich verstehe es nicht dann haben einige Sprachen auch noch extra Sicherheitsfeatures schon einbaut wie Isolation das ist ja also interpretierte JVM basierte Sprachen mehr oder weniger es ist auch bei aller echte Isolation aber zumindest hat man vielleicht keine Memory Leaks und hat gleich System Access und kann wirklich gleich Binarys ausführen die am Übersnetzwerk geschickt werden das ist üblicherweise je Low Leveliger die Sprache ist umso besser sind die Chancen und jetzt einen speziellen Anwendungsfall von irgendwelche Benutzeranwendungen mit UI und ähnlichen und für eher Programmieranfänger ist es meiner Meinung nach das ist jetzt sehr subjektiv natürlich und wir haben eine neue Fragerunde wo es euch eine Meinung dazu abgeben könnt aber ich finde rein aus der Sicht vom Wüffel man falsch machen kann sind Pfeifen Ruby Scharp eigentlich relativ nett weil zumindest Exceptions entgegenfliegen und das sehr oft sicher fehlt und es sie zumindest im meiner Wörter oft so verheult wie man es erwartet wiederum Java verheult sie meistens so wie man es erwartet aber man kommt oft in irgendwelche Memory Probleme und irgendwann ist der Hauptspeicher gar nicht das ist der Nabis sie umwitzig Java Script also gerade serverseitiges Java Script also Node.js und ähnliche haben mit diesen ganzen Frameworks sehr viele Varianten wie man Dinge machen kann und das ist nicht immer eindeutig und das ganze Dependency System hat zumindest Potenzial es falsch zu machen man sieht Java Script Server Entwicklersatz schaut das für euch vermutlich ganz anders aus und ihr habt da andere Meinungen dazu bei C und C++ überhaupt ohne die ganze Enterprise Toolchain mit diverse Automated Checks und Boundary Checks hat schon Potenzial sie Fehler dass irgendwie Fehler passieren und PRP ist in der Security Community gerade bei CTFs eigentlich schon fast a running gag geworden dass man irgendwelche Funktionen von PRP gibt wo man sie denkt das ist ganz klar das kann ein MD5 Funktion da fällt ein String ausser ich meine es ist auch schon komisch der MD5 ist aber weil das Stringhandling in PRP so sorgsam ist kommt da eventuell was anders ausser und meiner Meinung nach hat PRP gerade in der Standard Library also ich rede jetzt nicht von Cake und die ganzen Frameworks die ein bisschen was von der Hässlichkeit maskieren hat PRP doch oft gewisse Verhaltensmuster die zumindest für mich sehr unerwartet sind um das einmal sicher zu sorgen dann klassische Two Don'ts also natürlich jede Art von Evaluate also irgendwo kriegst du ein String und du evaluierst den als Code sofern das irgendwie vermeidbar ist und es ist eigentlich immer vermeidbar so wird man es auch vermeiden eigentlich ist es nur Variante davon weil steht euch ein Programm evaluiert es dann euch ein SQL Server weil jedes SQL Statement ist eigentlich ein Kommando und von daher ist Strings mit plus Samstöpseln mit Concatenation mit normalen String formatting alles was nicht prepared Statements sind ist einfach falsch und wenn sie irgendwo was sagt was auch an sich denkt wenn man an dieses stöhe User-Impot hinkommt man verwendet es einfach trotzdem prepared Statements sie sind auch effizienter und man muss sie auch mal erstönen und das Server ist und sie werden vorgepasst und es sind einige Dinge die haben prepared Statements cool sind aber verwendet es prepared Statements immer man sollt eigentlich meiner Meinung nach nicht einmal nicht prepared Statements mit irgendeinem dynamischen Input ausführen dann natürlich native Ausführung ist immer was was man in größere Projekte vermeiden kann und in viele Fälle sollte nicht immer man handelt sie extra Komplexität ein die natürlich auch zu Fehler führt aber grundsätzlich kann ich empfehlen dass man virtuelle Maschinen Docker, ChangeRoot und was es nu es gibt verwendet was davon das Beste ist hängt sehr davon ab was ein Projekt ist und in welchem Scope das ist und eventuell braucht es einen und dann was man sehr oft in Software sucht Blacklisting also dieser und jener Character ist verboten zum Beispiel das Script Tag ist in meinem Input verboten dann mache ich onError kann ja Script Code einbocken und irgendwann denkt sie naeche HTML Tags aus und wirft die gegen euch einen alten Code und dann geht es auch wieder und da weise wisst ihr bei euch am Input A mit einer Regex Lernz Regex was da herkommt um wie man das eventuell weitlisten kann also klar definierte diese Inputs sind ok und der Spezialfall davon ist grad bei HTML das leid eigentlich nur diese vier Zeichen Spitze Klammer auf doppeltes Hochkommer spitze Klammer zu und einfaches Hochkommer das nur desescaped wird es gibt immer wieder Angriffe wie man um diese Varianten herumkommt das muss natürlich immer encoded sein weil man irgendwie UserInput in HTML einbettet aber eigentlich ist es sicherer einfach alles außer A bis Z und Null bis Neu einfach einmal als HTML Entity mit und Hashtag und dem Hexcode zu encoden zu Sicherheit einfach mehr machen natürlich braucht es mehr Speicher natürlich ist euch HTML bis sie weniger hübsch da mit aber es ist sicherer und es ist auch code technisch einfacher als irgendwelche Ausnahmen zu überlegen debugging Features und Endpoints so hat man natürlich in einer produktiven in einer produktiven Umgebung Disabled sofern euch eine Testumgebung public ist auch und einige Programmiersprachen bieten dafür natürlich auch wieder Support kann ich es ja empfehlen am besten einfach gleich als eigenen Subservice starten und ein richtig großer Fehler dem auch immer wieder seht dass irgendwas nicht als Input gesehen wird Leid glauben, dein Useragent kann nicht 10 Megabyte groß sein Leid glauben, du kannst vielleicht einfach ausgeben weil da ist ja a SafeString dann gibt da ja der Browser kann man normal einstun Cookies, Sessions eigentlich alles was man irgendwie über API vom wem anderen grügt ist alles Input was aus deiner Datenbank kommt ist Input es muss nur irgendwer die und der Datenbank meint in den Mitteln selbst die Zeit wenn man NTP verwendet kann fremder Input sein wenn man Time Spoofing machen kann wenn das nicht alles secure eingestellt ist teilweise sind falls die User hochladen natürlich auch Input und eigentlich ist alles dynamische Input und man sollte niemals Input vertrauen das ist eigentlich eine der wichtigsten Sachen dann ich kann ja nicht nur PRP halten und das so stell lassen ich habe jetzt ein Beispiel von einem CTF ein Wettbewerbe wo man so simple Challenges kriegt und ich bin ein super Fan von sogenannten One Line Challenges also eine Zeile an Code und das wird am meisten über Netcat reingepiped und du kriegst über Netcat den Output zurück das heißt du kannst irgendwo hinverbinden und kannst in das Programm beliebigen Input reinschmeißen und jetzt haben wir da diesen Code einmal in wunderschönen PRP da will man was lernen das Add habe ich zum Beispiel vor diesem Beispiel noch nie gekannt Add ist der Shut the Fuck Up Operator der einfach alle Exceptions nimmt und weg haut in Java spreche es Try, Catch Empty also Null Exception Handling Ignoriere es, gib sie nicht aus und das macht eigentlich ich habe das dann nochmal in einem ähnlicher Sprach geschrieben du liest ein Pfeil, das da der User gibt vom Input und schaust dann ob es mit Shut the Fuck Up um PRP startet und dann inkludest du es was im PRP hast es auszuführen und an einem Fall gibt es ein Pfeil aus und Crossside Scripting ist in dem Fall k relevante Lösungen natürlich und jetzt kommt wieder der interaktive Teil kann man irgendwer sagen wie man diese eine simple Zeile PRP Code so beeinflussen kann dass sie deinen Code ausführt kann irgendwer bitte Mikrofonengel aufstehen falls es irgendwen gibt ich habe echte Hoffnungen wenn sie irgendwer trauen will es gibt sehr viele Varianten das zu beantworten nur eine ist aktuell aber der Versuch zählt bitte, irgendwer du schaust interessieren der Witz ist dieses Stück Code hat man in den letzten Jahren immer und immer wieder auf eine andere Variante exploiten können das coolste, neicheste Feature vom PRP sind Multi-Part-File Uploads im aktuellen Directory bei Default wenn du in Ubuntu PRP installierst und Apache ein File namens Upload unterstrich Progress, unterstrich Sex Random Bytes und dann haben wir auch noch was sehr cooles und sehr nützliches und überhaupt nicht dummes im PRP das nennt sie Filter und du kannst mehrere Filter aneinanderketten das ist dieses PRP Filter mit Schmipp-Tags zum Beispiel wenn wir irgendwo ein Text-File haben wo da HTML Text drinnen sind dann kannst du einfach alles was in diese Texte statt weggauen du kannst von in etwa 400 encodings in 400 andere encodings konverten du kannst to upper, to lower base 460 encoding decoding du kannst das aneinanderketten und eigentlich kannst du damit aus einem beliebigen Input wenn du diesen beliebigen Input lang nur gefilterst den beliebigen Output machen also nicht ganz aber du kannst z.B. aus diesem Upload Progress File durch base 64 encoding sagen dass du den ganzen Anfang weggeschnetzt du schaust dass der irgendwie in ein HTML-Tag kommt und machst dann Strip Tag dann machst du nur bis zu base 64 decoding encoding hin und her und auf und ab und auf einmal kannst du den Teil vor dem Padding weggauen und nur der Input ist dieses PHP-File und der PHP-File kann dann mit diesem add und PHP-Starttag anfangen somit kannst du auf dem Server über Multi-Part File Upload ein File platzieren das lokal inkludierbar ist und das ist bis Ende 2019 noch mal draufgekommen dass das vielleicht nicht bei default aktiviert sein soll der Witz ist PHP denkt sich da immer und immer wieder andere witzige Dinge aus z.B. PHP Memory, PHP Input Input ist einerseits der Input von Standard In aber auch der Body von Post Request das heißt man hat das File PHP Input öffnen können und das ist dann ausgeführt worden dass wir das File Input wollen dann natürlich das Schema Data Doppelpunkt also du kannst über den File Name den Inhalt angeben das wird im Web relativ oft für Bühner verwendet und PHP erlaubt das wird auch für Code weil es ja cool dann gibt es bis 2017 ein Standardfeature das File das du import das muss ja nicht auf dem Server liegen ist ja eine komische Annahme dass du denkst das muss auf dem Server liegen in jeder anderen Sprache geht das natürlich nicht das war bei CTF so mal eine Lösung weil diesen Oneliner hat es mehrere Varianten im mehrere CTFs geben aber im Prinzip dieses Beispiel wäre über die Jahre immer und immer wieder verwendbar gewesen was ich so witzig finde dann hat es PHP Archives geben das sind im Prinzip sehr realisierte Dateien und da hast du ein Destruktorkode mitgeben können du hast PHP Code der onDestruct ausgeführt worden ist und der beliebigen Code beinhalten kann mitgeben können in diesem File das heißt wenn du da dachtest die gibt jetzt dem User in einem Cookie vielleicht sei ganze Session und dann holen wir die wieder aus dem Cookie das haben wir schickt hast du ein Destruktoreinbauen können ja dann eben UploadProgress die aktuellen Schema die PHP alle unterstützt sind eben all diese gefreut mir jetzt nicht aufzuholen und PHP ist ein Metatag der hat dann verschiedene PHP-Metashemas wie Stripfilter und so weiter erlaubt und das ist eben meiner Meinung nach ein Beispiel für eher unerwartetes Verhalten das ist nur dazu eher schlecht dokumentiert ist gerade dieses Filterbeispiel war so kompliziert weil es genau im englischen PHP manuell eine Page dazu gibt und man dann mal genau findet welche Filter es alle gibt dann nur ein zweites Beispiel zu unerwarteten Verhalten diesmal im Pfeifen Pfeifen mögen wir doch alle Pfeifen ist so cooler Sprach little fun fact zu Pfeifen außer exceptions wird nichts groß geschrieben im Prinzip und exceptions sind normalerweise ein Kamer Case und Title in den ersten echten Buchstaben in einem Word-Upper-Case und Class-Names-Sun und Import kannst du zum Beispiel auch schon nicht machen weil es ist auch schon case-sensitive und groß geschrieben import hast nix haben wir irgendwelche Pfeifen-Profis da die sich jetzt denken, ich kann diesem Script ein Input geben so dass ich beliebige Code-Executions auf diesem Server hab freut euch irgendwas ein bitte, irgendwer ist ebenfalls spannend weil es ist wieder ein Feu von unerwarteten Verhalten und zwar die Evaluate Funktion nimmt ein String der so encoded ist, ihr kennt's ein File haben, das Backslash Octal encoding Backslash Octal encoding das kann ein Text-File in dem das drinsteht das kann natürlich ein String sein die Evaluate Funktion gibt und natürlich machst du zuerst in dieser Zeile Title-Case das ist ein neues Octal Title-Case macht natürlich gar nix das sind Numbers, gibt keine Upper-Case Numbers und ich hab da jetzt einen einfachen encoder du gibst dem Ding ein String und der wandelt den String in Octal encoding um vermutlich wäre es in einem hübschen One-Liner-Gang auf jeden Fall und so kannst du diesem Script Print High geben und es führt dann halt High aus und das war die Lösung, du hast einfach nur den Code an diesen Server schicken müssen mit Print Flag und das ganze Octal encoded ist ebenfalls was, was man extrem schwer in der Dokumentation findet, weil die Evaluate Function vom Pfeifen einfach nicht wirklich gut dokumentiert ist und auch wenn man sie vom Pfeifen selbst auf Git anschaut ist es relativ schwer dieses Verhalten zu finden und jetzt noch was zum mit Hamnehmer, wir sind jetzt am Ende vom Talk, coole Payloads zum Server ausprobieren auf der Obasp-Site gibt es nur ein bisschen mehr es gibt einerseits natürlich Script Alert One Script auf einer Website und es geht darum, dass der JavaScript ausführt der Basetag ist ganz witzig dazu einmal die Dokumentation zu lesen der setzt die aktuelle Seite, also wenn sie Relative Links habt, auf irgendwas komplett anders ihr kennt sie im Basetag auf google.com und jeder Relative Link geht dann auf google.com slash diese Relative Pfad damit lassen sie auch ganz witzige Cross-Site Scripting Sachen machen, wenn sie diesen Basetag checken kannst dann auch ein Schema beinhalten sind so die spannenden Dinge, da hat es einmal einen witzigen Exploit gegeben natürlich einfach Closing Tags einfügen und schauen ob vielleicht das ganze HTML einfach auseinanderfeilt weil euch ein String jetzt zum Tag zu macht Unload ist natürlich immer witzig, wenn man irgendwo mal einfügt, wenn wer überhaupt keine Quotes macht in CSS gibt es das witzige Konzept von Timing Attacks wir haben CTF was ganz witziges weil man in CSS Selektoren machen kann, die relativ zeitintensiv sind das ist dieses heißen Sternding das genau dazu müsst ich einlesen aber wenn du irgendwo CSS Injecten kennst, kennst du damit eigentlich Input von der Seite auslesen wenn du diese Timings auslesen kennst SQL ist natürlich entweder dass man ein Minus Minus start of comment ich glaube die Formatierung habe ich es sich falsch gemacht aber dass man im Prinzip bei einem wachs sorgt Statement bis da her all to und statt true kann man einfach an das gleiche anzuschreiben weil je nach SQL Dialect to anders geschrieben werden muss und damit findet man eventuell Besuch wie wie schon bessere Outputs wenn man irgendwie vermutet die Hintergrund ist irgendwas mit Buffer mit C und dynamischen Speicher erarbeitet schmeißt man einfach einmal ein Kilobyte megabyte an ars dagegen und wenn da irgendwo ein Segmentationfall kommt oder irgendeine Webdinger mal gar nicht replied dann weißt du das war auf EC und da hat irgendwo ein falsch dynamisches Memory allokiert es sind auch nur immer Dinge die man ab und zu sirkt oder bei irgendwelche Inputs einfach HTML encoded %00 das ist der end of string tag in C in Templating Engines ist natürlich doppelte geschwungene Klammer in diverse Java und Python based Engines waren da auf einmal 2.0 statt geschwungene Klammer 1 plus 1 dann wird wo ihr das was ihr eingeben habt evaluiert und dann hat wir irgendwie Print gemacht und das ist irgendwie evaluiert worden es gibt ein Haufen Schemas wenn irgendwer von euch ein Url erwartet macht's einfach mal K htdp htdps url macht's mal file macht's mal data macht's mal PAP Archive ja natürlich alles was irgendwie im Hintergrund Shell called also so IP Lookup Tools gibt's durchaus nur in the wild oder wenn irgendwas über 3 Ecken durch a Shell durchgeht einfach einmal dieses Backtick der in der Shell Evaluation macht einzelne oder doppelte Hochkammer weil wer meistens seinen Input einfach darin rappt wenn er sich dann auf Fehler entgegenflirgt in XML gibt's was ganz nettes und XHTML ist, weil die das XML und wenn man Server-Site Rendering von HTML macht meistens zur Validierung dann sind solche Dinge möglich das würde ich zum Beispiel in eichern Code die etc. Password direkt einbinden man sich dieses XML Element führt das bei einem Standard XML-Paser wie der Java-Sax-Paser den man Local File Inklusion erlaubt mittlerweile ist das natürlich nicht mehr erlaubt aber einige PAP XML-Paser haben das bei Default nun kannst du einfach irgendein System File am Server inkluden lassen oder in Memory und ist ebenfalls was ganz spannendes Filter Bypassing das haben wir bei CDFs oft vielleicht in einer Firewall einfach Script oder PAP oder Input zu einer gewissen Länge blocken dann macht man einfach das Case Upper Case, Lower Case, Mixed im Internet wird das gerne Emo Case genannt also ja Double Encoding teilweise wird was nur einmal encoded und decoded und gibt's ganz interessante OWASP-Artikel dann wird man halt die spitze Klammer doppelt encoded das heißt einmal wird's zu %3C und dann wird dieses % encoded und das wird zu %25 und wenn man dann einmal decoded wenn man seine eigene Templating Engine geschrieben hat dann kann das zum Beispiel schiefgehen das sind so typische Fehler die OWASP blistert und Teile davon habe ich auch schon in der Wald gesehen ja wir haben jetzt einerseits Fragen bitte programmiersprachendiskussionen oben in der Bar aber nicht im Recording also es stürzt sonst keiner Fragen dann machen wir programmiersprachendiskussionen ja und habe irgendwas vergessen und wir haben schon die erste Frage warte kurz, warte kurz, Mikro fürs Recording ich trau mich kurz an die Grenzen der Regeln was ist mit so Dingen wie Nougat Package Include und Dependencies besonders im Hinblick auf Dependencies die schlecht gepflegt sind ist immer schwer weil du eigentlich ein bisschen Safety gegen Security abwiegen musst also es kann doch nicht einfach wenn du ein schlechter Pack-up-Management-System verwendest sind solche Systeme überhaupt mit Auto-Updating irgendwie so ein mittel guter Idee gerade bei Java Script hat sie mit diesem mal geben irgendwer hat das aus dem Repository einfach gelöscht und dann sind mehrere Tausende Java Script seitens mit Auto-Updaten nicht mehr gegangen, weil die haben Left Padding verwendet andererseits ist es ganz cool weil du Updates von Framework-Ersteller kriegst und ich habe da sehr gespaltene Meinungen aber ich kann teilweise eher empfehlen wäre sie ohne ein Hard-To-Code und sie einmal im Jahr zu überlegen vielleicht einmal diese Dependencies MPM Upgrade oder was ja immer du da so hast oder Nougat Upgrade einmal im Jahr zumindest zu machen und zu schauen ob es nur immer funktioniert aber Auto-Update und allgemein so halb gut gewartete Systeme sind immer ein bisschen ja schwer gibt es sonst nur Fragen gibt es vielleicht doch Programmiersprachen-Diskussionen ok dann haben wir nur auch Fragen und dann sind wir eher out of time anscheinend ich verschärfte es einmal gerade bei den Dependencies es gibt den Nougat Packages-Geschichten und Leute die da zuneigen nicht zu schauen wie gut gepflegte Libraries sind es gibt aber Sprachen die schon Tool-Unterstützung haben um nachzuschauen ob kaputte Dependencies verwendet werden wir sind also weitergehen wird es dann natürlich in Richtung wie mache ich im Vorfeld also bevor der Pentester kommt automatisiertes Testen in Bezug auf Sicherheitsfragen oder sogar Verfahren wie mache ich meine Software-Entwicklung sicher und die Ecke wo ich gerne raus will ist wie kann man aus deiner Sicht sichere Verfahren der Software-Entwicklung kombinieren mit Pentests damit man die maximale Sicherheit, den maximalen Effekt erreicht ja meiner Meinung nach so jetzt du alleine schon mal eigentlich 200% Testcoverage nicht nur wenn der Code funktioniert sondern was passiert wenn man den Code in irgendein Error-Case manövriert ist es einmal wichtig meiner Meinung nach manövriert dann ist es ein LOUD Poolchain mit Automated Building dann eben Linter und wenn du irgendetwas eher low leveliges verwendest gibt es auch Weltgrind und andere automatisierte Tools wo du memory leaks vermeiden kannst wenn ich irgendwo ein Projekt sehe das exotische Impards hat dann schaue mich meistens an hat, nie mehr mal einfach an, dass da schon irgendwer drüber geschaut hat, der Securitykompetenzen hat. Wenn es einen Contributor gibt und der letzte Kommitt 2013 war, dann mache ich das zumindest einmal auf und check das einmal aus. Aber ich glaube an OS haben wir gibt es eigentlich meiner Meinung nach nicht der alle Probleme erschlagt. Aber ein guter Toolchain und ein guter IDE sagt da schon mal ein Haufen Sachen, die schiefgekennend, also Sona und normales Linting und IntelliJ, wenn du ein Java-Mensch bist, sind coole Sachen, die empfehlen kann zumindest. Eigentlich sind Security-Fehler auch nur Programmierfehler, die oft durch schlechten Stil oder grausliche Sachen entstängern. IntelliJ wandt schon oft, wenn du in der SQL-Ding ein Concatinated-String einigst, schiebst zum Beispiel. Einige ganz billige Sachen kann man schon automated machen. Also arbeitet auch eine Firma, die dynamische Analyse macht, gerade an automatisierter Security-Analyse. Aber das fährt es noch sehr näher und ja, es ist schwer, aber finde ich toll, dann habe ich noch einen Job. Dann Sorge, danke und ja, ich glaube das war's. Danke für die Aufmerksamkeit.