Einblicke in sichere Codes

Secure Code Warrior is deeply committed to helping educate the security and developer community on how to write code securely as well as mitigate the risk of vulnerabilities introduced through insecure code. As part of this goal, we will be utilizing the developing story of Uber’s recent security incident as an opportunity to discuss the importance of developer driven security and shifting left.

Security Incident at Uber

Uber released a statement about the cyber security incident on September 16th and they continue to update it. Readers should keep in mind this is an ongoing story. Let’s recap what we’ve learned through Uber’s announcement so far and other reputable posts in the security community. 

The hacker started by socially engineering an Uber employee, after having found their What’sApp number. The attacker contacted them and started phishing for credentials by having the unsuspecting employee login to a fake Uber site and then capturing their username and password. 

Uber accounts are protected via Multi-factor Authentication (MFA), meaning that apart from submitting a password, the user must present a second piece of evidence that confirms their identity. In most cases, this is a prompt sent to a mobile device. 

After obtaining the credentials, the attacker initiated an MFA fatigue attack by continuously trying to login to the genuine Uber site, and overwhelming the employee with numerous push notifications on their device. Again, the attacker contacted the victim via WhatsApp. This time they allegedly pretended to be IT support and successfully convinced them to accept.

Hardcoded credentials

At the basis of Uber’s security breach was a successful phishing attack. Once inside, the intruder found network shares containing PowerShell scripts. One of these scripts contained an admin user’s hardcoded credentials, which led to the compromise of Uber internal services, such as AWS, G-Suite, and code repositories. The hacker also got access to Uber’s HackerOne account. According to Uber, however, “any bug reports the attacker was able to access have been remediated."

Curious to see what this vulnerability would look like in code? Try out our PowerShell challenge for free.

How common are these types of attacks?

Social engineering as an attack vector is difficult to defend against, as the human factor has always been considered the weakest part of cyber security. The Uber hack has clearly illustrated that MFA implementations can easily be circumvented. The key to preventing this is creating more awareness amongst employees about the workings of phishing attacks. 

What caused the exposure of Uber’s internal services, however, are the admin’s username and password that were found in a PowerShell script. Hardcoding credentials is never a good thing, as they become readable to any developer, and basically anyone with access to the code. 

But again, awareness is key! Developers with a security-centered mindset are more likely to spot vulnerabilities, and less likely to write them.

A two-pronged approach of general education on social engineering, and more specifically, proactive secure coding training, will reduce the number of vulnerabilities in a code base, and therefore prove to be critical in the fight against security threats.

Want to learn more about staying up to date with secure coding best practices? Check out Secure Code Coach. Here you can learn secure coding guidelines and tryout training exercises for free.  

... ein Dritter hat auf dein Repository zugegriffen, indem er den richtigen Benutzernamen und das richtige Passwort für einen der Benutzer verwendet hat, die die Erlaubnis haben, auf dein Repository zuzugreifen. Wir glauben, dass diese Anmeldeinformationen möglicherweise über einen anderen Dienst durchgesickert sind, da andere Git-Hosting-Dienste einem ähnlichen Angriff ausgesetzt sind.

Als Nutzer eines webbasierten Dienstes ist es nie eine gute Erfahrung, eine solche E-Mail über einen möglichen Verstoß gegen Ihre persönlichen Daten zu erhalten. Stellen Sie sich nun vor, dass es sich bei den Daten um ein Code-Repository handelt, das Ihre harte Arbeit oder sogar die Geschäftsgeheimnisse Ihrer Software repräsentiert. Mindestens 392 (bisher) GitHub, Bitbucket und GitLab Benutzer haben diese Woche diese herzzerreißende Benachrichtigung erhalten, und was noch mehr ist - ihr Code wurde von den Angreifern heruntergeladen, aus dem Repository gelöscht und als Lösegeld erpresst. Sobald alle Dateien der betroffenen Benutzer verschwunden sind, bleibt nur noch eine Textdatei mit dieser Meldung übrig:

Im Gegensatz zu den meisten anderen berichtenswerten Unternehmensverstößen (und sogar frühere Angriffe auf GitHub) wurde dieser nicht durch einen Bug auf ihrer Plattform verursacht. Vielmehr wurden Kontoinformationen unsicher im Klartext gespeichert und sind wahrscheinlich aus Repository-Management-Diensten Dritter durchgesickert. Entwickler haben aktiv wichtige Passwörter falsch gespeichert und häufig dieselben Zugangsdaten für mehrere hochwertige Konten wiederverwendet.

Es scheint, dass die Betrüger nicht die besten und klügsten der Programmierwelt sind, da (zum Zeitpunkt des Schreibens) kein einziger Benutzer das Lösegeld gezahlt hat, um seinen Code wiederherzustellen, und einige clevere sicherheitsbewusste Leute haben bereits Problemumgehungen für betroffene Benutzer gefunden gelöschten Code wiederherstellen.

Dennoch werden dadurch Probleme aufgezeigt, die wir in der Sicherheitsbranche seit langem kennen: Die meisten Entwickler sind einfach nicht ausreichend sicherheitsbewusst, und wertvolle Daten können jederzeit gefährdet sein... selbst für diejenigen, die keine Hacker-Genies sind.

Warum ist unser Passwortmanagement immer noch so schlecht?

Menschen haben natürlich Fehler, und wir neigen dazu, uns das Leben leichter zu machen. Es ist sicherlich viel einfacher, denselben Benutzernamen und dasselbe Passwort immer wieder zu verwenden, und es ist viel einfacher, sich den Namen Ihres ersten Welpen zu merken, als „z7B3#! q0HWxXv29!“ einzugeben nur um auf Ihre E-Mail zuzugreifen. Da jedoch ständig so viele groß angelegte Cyberangriffe stattfinden, sollten Entwickler es inzwischen wirklich besser wissen.

GitHubs eigener Rat In dieser Angelegenheit war es einfach zu beurteilen, dass dieser Lösegeldangriff nicht stattgefunden hätte, wenn eine Zwei-Faktor-Authentifizierung eingeführt worden wäre und sichere Passwortmanager verwendet worden wären. Das ist absolut richtig, aber wie ich immer wieder sage, es ist klar, dass die Bildung noch weiter gehen muss. Alle Entwickler müssen — auf einer grundlegenden Ebene — verstehen, warum bestimmte Aktionen ihre Konten anfällig für Angriffe machen könnten.

Bildung: Die magische Pille?

Sicherheitserfahrene Programmierer wissen, dass ein einfacher Fehlkonfiguration der Sicherheit kann verheerende Folgen haben, und im Fall dieses GitHub-Angriffs scheinen falsch konfigurierte Dateien dazu beigetragen zu haben, dass die Angreifer erfolgreich bösartige Skimmer injizieren konnten, um die Schlüssel zu ihren Schlössern zu finden.

Offenlegung sensibler Daten ist ebenfalls eine kritische Sicherheitslücke, die es zu überwinden gilt und immer noch auf Platz drei der OWASP Top 10 steht. Das Speichern von Passwörtern im Klartext ist ein klarer Beweis dafür, dass viele nicht verstehen, welche Gefahren damit verbunden sind und wie leicht Systeme durch Brute-Force-Passwortangriffe durchbrochen werden können.

Das Verständnis der Kryptografie (und insbesondere des kryptografischen Speichers) ist eine wichtige Komponente für die Verwaltung von Passwörtern in einer Codebasis mit eiserner Sicherheit. Wenn alle gespeicherten Passwörter erfolgreich gesalzen und gehasht werden, um ihre Eindeutigkeit zu erzwingen, wird es weitaus schwieriger werden, Situationen wie diesen Lösegeld-Vorfall zu erzwingen.

Es ist wichtig zu verstehen, dass sich unsere kollektive Einstellung zur Sicherheit ändern muss, wobei der Schwerpunkt mehr auf einer angemessenen Ausbildung der Entwickler und der Ernsthaftigkeit von Cyberbedrohungen liegen muss. Wir müssen das Lernen über Sicherheit zu einer positiven und lohnenden Erfahrung machen, und ich denke, das wird für eine allgemeine Anhebung der Standards für alle Entwickler, die ihre Arbeit selbst beurteilen, von grundlegender Bedeutung sein.

Möchten Sie versuchen, die Sicherheitslücken zu beheben, über die Sie hier gelesen haben? Du kannst verwandte Herausforderungen auf spielen Sicherer Codekrieger gerade jetzt:

• Fehlkonfigurationen bei der Sicherheit
• Unsicherer kryptografischer Speicher
• Offenlegung sensibler Daten

A version of this article appeared in DevOps.com. It has been updated and syndicated here.

The playing field between the heroes and villains in cybersecurity is notoriously unfair. Sensitive data is the new gold, and attackers adapt quickly to circumvent defenses, exploiting security bugs large and small for potential paydirt.

The volume of code being produced is too great for security experts -- of increasing scarcity -- to contend with, and the rising cost of data breaches is proof that something has got to give. Fortunately, for the sake of our digital safety and the sanity of CISOs everywhere, the DevSecOps movement is helping to bring developers on the security journey from the beginning of the software development process. They are being recognized as the first line of defense against cyberattackers, with the power to eliminate common vulnerabilities at their fingertips.

However, their defensive capabilities are only as good as the training they receive, and that is yet another gauntlet for security teams to run. For many developers receiving training in secure coding on the job, their key challenge is staying awake during mind-numbing, hands-off activities that are neither effective, nor inspiring them to keep security front-of-mind. Soulless video courses aren’t getting us there, token annual ‘tick-the-box’ events are a waste of time, and nobody is winning against the potential malicious threat actor waiting to jump on a small window of opportunity.

At this stage in our industry, we have worked out that contextual, hands-on education that is delivered in relevant programming languages and frameworks, with challenges that mimic those a developer might come across in the real world, is a far more engaging approach.

This is phase one of a developer’s quest to help AppSec gurus slay common vulnerabilities, but phase two is where scenarios must get real for a supercharged, security-aware defensive force.

Scaffolded learning is critical in adult education

When it comes to extracurricular courses or on-the-job training, it is often overlooked that adults bring with them a certain level of experience and existing knowledge. Good training adds to this foundation, and is structured in a way that allows for deeper understanding and faster autonomy in the learning process.

Scaffolded education is a potent, positive method of learning that seeks to activate and enhance prior experience, while continuing to build new skills  - in manageable chunks - that allow the tutee to tackle increasingly difficult tasks with more confidence. Typically, it is a methodology best served with healthy portions of demonstration, visual aids, and student-led exploration.

If we tie this approach back to developer security training, it comes as no surprise that the dynamic, learn-by-doing method has long been preferred over the drudgery that is theory-based static learning. They are free to be the masters of their domain, and should see that their time is well spent.

In that sense, learning to code securely in a hyper-relevant, contextual environment is key, but the ‘level up’ from this step is to see an exploit of vulnerable code in action. With the context of frontend and backend views side-by-side, there is a tangible link between actions taken during the coding process, and what an attacker can potentially do with cut corners, misconfigurations, or accidents that are not caught and remedied.

Move from recall to application for a truly preventative security approach

Experiencing the impact of security vulnerabilities first-hand is a vital piece of the education puzzle, and it’s a fairly rare beast, even with the most modern security training options for developers. The foundational work spent on honing skills in spotting and remediating vulnerabilities, and recalling that experience to eliminate the same bugs in code as it is being written is extremely important, but it’s not the whole picture. To see how vulnerable code is exploited by a malicious actor adds a powerful layer of context, one that really drives home the importance of securing code, and applying hard-earned security knowledge to close every window of opportunity.

It is generally accepted that developers don’t love security, and they have even less affection for security training. Their experiences with AppSec specialists can be very frosty, and the rework caused by the security team bouncing vulnerable code back to developers for remediation is the bane of their existence. To an engineering team that is already spread thin, security is someone else’s problem, not their priority, and a hindrance to their natural creativity and primary objective of building features. However, there is simply too much code, too many breaches, and too much risk to the world’s data for this mindset to continue.

A functional DevSecOps process has developers working in harmony with security teams right at the beginning of the SDLC, and the opportunity for applied learning where they can interact with a simulated exploit, and see the impact of poorly secured code goes a long way in getting developers on the same page as those pesky AppSec people (who aren’t so bad after all).

Interactive learning prepares developers for the boss fight

At the time of writing, there were two major breaches reported in a 7-day period: Razer announced that over 100,000 sensitive data records had been exposed, while office supplies chain Staples also reported a similar data leak. Over a billion sensitive records have been exposed so far in 2020, and this worrying trend shows no signs of slowing down. Simply put, malicious actors have the upper hand, and security-aware developers are sorely needed to serve as the front line of defense.

Interactive challenges that focus on simulating such breaches move developers from passive recall, to applying skills that have an impact on the real boss fight: stopping attackers in their tracks.

‍

Eine Version dieses Artikels erschien ursprünglich in Hilfe | Net Security. Es wurde hier aktualisiert und syndiziert.

‍

Wenn Sie in einer praktischen Rolle im Bereich Cybersicherheit tätig sind — eine Rolle, die eine gewisse Vertrautheit mit Code erfordert — stehen die Chancen gut, dass Sie über SQL-Injection nachdenken mussten... immer und immer wieder. Es handelt sich um eine weit verbreitete Sicherheitslücke, die, obwohl wir wissen, dass sie innerhalb weniger Wochen nach der ersten Entdeckung relativ einfach behoben werden kann, unsere Software weiterhin plagt und potenziellen Angreifern ein kleines Zeitfenster bietet, wenn sie vor der Bereitstellung unentdeckt bleibt.

Am 13. Dezember 2020 jährte sich der 22. Geburtstag von SQL Injection, und obwohl diese Sicherheitslücke alt genug ist, um sie zu trinken, lassen wir uns von ihr überwältigen, anstatt sie endgültig zu zerquetschen. Im August dieses Jahres gab Freepik Company bekannt, dass sie ist einem SQL-Injection-Fehler zum Opfer gefallen das kompromittierte die Konten von 8,3 Millionen Nutzern. Während einige von ihnen Drittanbieter-Logins nutzten (z. B. Google, Facebook), waren bei einigen Millionen unverschlüsselte Passwörter zusammen mit ihrem Nutzernamen offengelegt worden. Leider bereiten ihnen und vielen anderen die Folgen dieser Vorfälle große Kopfschmerzen, und der Wiederaufbau des Vertrauens in die Nutzerbasis ist ein langfristiger Prozess.

Wir „feiern“ diesen Meilenstein zwar mit einem Thema, das als Altlast angesehen wird, aber lassen Sie uns ihn für einen Moment analysieren. Warum taucht es immer wieder auf, warum ist es immer noch so gefährlich, dass es seit Jahren nicht mehr von der Spitze der OWASP Top 10 herausgekommen ist, und warum schafft es seine relativ einfache Lösung nicht in die allgemeinen Benchmark-Standards für Softwareentwicklung?

Warum ist SQL Injection 2021 immer noch relevant?

Ein kurzer Blick auf einen kürzlich aufsehenerregenden Verstoß, den verheerender Cyberangriff auf FireEye, zeigt ein erstaunliches Maß an Raffinesse: Es war ein hochkoordinierter, nationalstaatlicher Angriff, bei dem eine Vielzahl fortschrittlicher Techniken zum Einsatz kam, die für einen FireEye-Überfall maßgeschneidert zu sein schienen. In einer Erklärung sagte Kevin Mandia, CEO von FireEye:

“Die Angreifer haben ihre erstklassigen Fähigkeiten speziell auf Ziele zugeschnitten und Attacke FireEye. Sie sind in Sachen Betriebssicherheit bestens geschult und werden mit Disziplin und Konzentration ausgeführt... sie verwendeten eine neuartige Kombination von Techniken, die wir oder unsere Partner in der Vergangenheit nicht kannten.“

Das ist ein Albtrauminhalt für jeden CISO, und wenn FireEye so etwas passieren kann, dann wird dadurch ins rechte Licht gerückt, wie verwundbar viele Unternehmen wirklich sind.

... außer, es ist sogar schlechter Neuigkeiten für ein durchschnittliches Unternehmen. FireEye ist eines der bekanntesten Cybersicherheitsunternehmen der Welt, und für den erfolgreichen Angriff auf das Unternehmen waren Gauner auf Mastermind-Ebene gefragt, die alles, was sie hatten, in einer koordinierten, groß angelegten Ausführung warfen. Für viele Unternehmen könnte eine lukrative Datenschutzverletzung möglich sein, indem sie einen einfachen Bug ziemlich schnell ausnutzen, ohne dass ein Mastermind erforderlich ist. Und SQL-Injection ist ein gängiges Beispiel für Letzteres. Es wird immer noch von Script-Kiddies genutzt, die im Dark Web schnell Geld verdienen wollen.

Im Mai 2020, ein Mann wurde wegen Kreditkartenhandels und Hackerdelikten angeklagt, als bei ihm digitale Medien gefunden wurden, auf denen Hunderttausende von aktiven Kreditkartennummern gespeichert waren. Er sammelte sie alle mithilfe von SQL-Injection-Techniken ab, ein Vorgang, der viele Unternehmen und Millionen ihrer Kunden gefährdete.

Als Branche sind wir sind Es verbessert sich ständig, aber SQL-Injection ist immer noch eine erhebliche Bedrohung und betrifft weit mehr als ältere oder ungepatchte Systeme.

Warum Entwickler es am Leben erhalten (und warum es nicht ihre Schuld ist)

Wir sagen immer wieder, dass SQL-Injection einfach zu beheben ist und Code so geschrieben werden sollte, dass er überhaupt nicht eingeführt wird. Wie bei den meisten Dingen ist es nur einfach, wenn Ihnen beigebracht wurde, wie man es richtig macht.

Hier beginnt das Rad im Softwareentwicklungsprozess zu wackeln. Entwickler machen dieselben Fehler, was zu wiederkehrenden Sicherheitslücken wie der Infiltrierung einer Codebasis durch SQL-Injection führt. Dies sollte jedoch keine Überraschung sein. Die meisten Ingenieure schließen ihr Studium ab, ohne viel über sicheres Programmieren gelernt zu haben, wenn überhaupt. Die meisten Schulungen am Arbeitsplatz sind unzureichend, insbesondere in einem Umfeld, in dem Sicherheit in ihrer Rolle nicht als Geschäftspriorität angesehen wird.

Wir geben Entwicklern keinen Grund, sich Gedanken über Sicherheit zu machen, und auch keine starke Plattform, auf der sie anfangen können, sicherheitsbewusster zu werden. Schlechte Codierungsmuster halten Bugs wie die SQL-Injection am Leben, und wir müssen mehr Wert auf das Sicherheitsbewusstsein der Entwickler legen und ihnen die Zeit geben, einen höheren Standard an sicherem, qualitativ hochwertigem Code zu schreiben. Das Schreiben von sicheren Codierungsmustern kann länger dauern, aber die damit verbrachte Zeit führt zu Effizienzgewinnen, die sich später im Prozess von unschätzbarem Wert erweisen.

Wird es jemals eine SQL-Injection-Beerdigung geben?

Eine Begräbnismetapher ist ein bisschen morbid, aber in Wirklichkeit wären unsere sensiblen Daten sicherer, wenn die SQL-Injektion endgültig zum Erliegen käme. Ich bin jedoch sehr zuversichtlich, dass wir noch ein paar Geburtstage feiern werden, bevor es soweit ist, denn die Kultur rund um präventive Sicherheit und die Betonung der sicheren Codierung hat sich einfach nicht genug weiterentwickelt, um den Sarg zugenageln zu können.

Neuere, robustere Sprachen wie Rust tragen dazu bei, einige der Bugs zu beseitigen, mit denen wir uns seit langem befassen, indem sie sicherere Funktionen verwenden, aber es gibt eine enorme Menge an veralteter Software, älteren Systemen und Bibliotheken, die weiterhin verwendet werden und potenziell anfällig sein werden.

Die gemeinsame Verantwortung für die Sicherheit im Entwicklungsprozess (hallo, DevSecOps) wird entscheidend sein, wenn wir wollen, dass „einfache“ Exploits endgültig abgeschaltet werden. Entwickler müssen von Anfang an mit auf die Reise genommen und dabei unterstützt werden, Verantwortung für ihren Beitrag zur Erstellung von sichererem und besserem Code zu übernehmen.

Wie sollten Entwickler vorgehen, um einen SQL-Injection-Bug in ihrem Code zu beheben?

Wir haben eine zusammengestellt umfassender Leitfaden für Entwickler, die lernen möchten, wie man SQL-Injection identifiziert und repariert. Komplett mit einer spielerischen Herausforderung in der Programmiersprache ihrer Wahl (sogar COBOL!) , dies bietet einige großartige grundlegende Lerninhalte, die jedem Entwickler helfen werden, sichereren und qualitativ hochwertigeren Code zu erstellen.

Anfang dieses Monats Belgischer Käfer-Kopfgeldjäger, Inti De Ceukelaire hat einen kreativen Hack veröffentlicht, der Hunderte von Unternehmen betrifft. Der Trick besteht darin, fehlerhafte Fehler auszunutzen Geschäftslogik in beliebten Helpdesk- und Issue-Trackern, um Zugriff auf Intranets, Social-Media-Konten oder meistens auf Yammer- und Slack-Teams zu erhalten. Sie können mehr über die Details lesen auf Intis eigener Blogbeitrag. Ich war beeindruckt von der Kreativität, die nötig war, um diesen Exploit zu entwickeln, und neugierig auf den Prozess. Deshalb habe ich beschlossen, Inti einige Fragen zu stellen, und ich teile seine Antworten mit Ihnen.

Hallo Inti, kannst du dich unseren Lesern kurz vorstellen?

Ich bin Inti, Bug-Kopfgeldjäger bei Intigriti und Hackerone. Ich lebe in Aalst (Belgien) und verbringe meine Tage damit, Sachen kaputt zu machen.

Letzte Woche habe ich deinen Blogbeitrag über das gelesen, was du seitdem „Ticket Trick“ genannt hast, und ich war beeindruckt von deiner Kreativität, diesen Exploit zu finden. Wie bist du auf die Idee gekommen, diesen Trick auszuprobieren?

Ich nehme an Bug-Bounty-Programmen teil, was bedeutet, dass bestimmte Websites verantwortungsvollen Sicherheitsforschern, die einzigartige Sicherheitslücken entdecken, Geld anbieten. Da es eine Menge Konkurrenz gibt, müssen Sie weiter nach Dingen suchen, die andere noch nicht gefunden haben. Ich fand Slack ein interessantes Angriffsvektor, weil es oft vertrauliche Informationen enthält und manchmal nur eine gültige Unternehmens-E-Mail benötigt. Also schnappte ich mir ein Bier, legte mich aufs Sofa und fing an, über alle möglichen Angriffsvektoren nachzudenken. Plötzlich hatte ich diese verrückte Idee — und es stellte sich heraus, dass sie funktioniert hat. Ich probiere generell alles aus, was mir in den Sinn kommt. Auch wenn das nur ein paar Mal funktioniert, zahlt es sich aus. ;-)

Als jemand, der normalerweise auf der anderen Seite arbeitet und versucht, Code zu sichern, frage ich mich oft, wie eine Pentest-Sitzung aussieht. Wo arbeitest du? Machst du das auch in deiner Freizeit von deiner Couch aus? Oder sitzt du in einem Büro?

Tagsüber arbeite ich als digitaler kreativer Programmierer bei einem Radiosender namens Studio Brussel. Es beinhaltet einige Programme und einige soziale Medien, aber keine Sicherheit. Ich versuche, mein Hobby nicht mit meinem beruflichen Beruf zu vermischen. Ich fürchte, ich würde meine Kreativität verlieren, wenn ich das täte. Ich hacke nicht oft: maximal ein paar Stunden pro Woche. Es kann am Tisch, auf der Couch oder auf meinem Bett sein — was auch immer gerade bequem ist.

Wie fängst du an? Hast du einen Spickzettel? Haben Sie einige Eingaben, um zu testen, ob eine ausreichende Eingabevalidierung oder ein Output-Escaping erfolgt?

Ich bin wirklich chaotisch, also habe ich nicht wirklich eine Checkliste, ich benutze nur mein Bauchgefühl. Die meiste Zeit beginne ich mit etwas namens Recon: eine Auflistung aller interessanten Zielinformationen, Subdomains, IP-Adressen, was auch immer ich finden kann. Ich versuche, das Gesamtbild zu sehen und die Geschäftslogik zu verstehen, bevor ich überhaupt mit dem Hacken beginne. Wenn Sie nur nach den üblichen Sicherheitslücken aus dem Lehrbuch suchen, werden Sie viele der clevereren und komplexeren Fehler übersehen. Wenn es um Eingaben geht, versuche ich, so viele Sicherheitslücken wie möglich in einer Nutzlast abzudecken. Immer wenn ich etwas Interessantes entdecke, spiele ich eine Weile damit herum und werfe eine Menge Unsinn hinein, nur um zu sehen, wie das System darauf reagiert. Die besten Bugs finden sich oft in den entlegeneren Teilen einer Webanwendung, also versuche ich so tief wie möglich zu graben.

Was macht deiner Meinung nach einen guten Pentester aus? Hast du irgendwelche Tricks im Ärmel, die du uns teilen kannst?

Ich bin kein Pentester, daher kann ich nicht wirklich für Pentester im Allgemeinen sprechen, aber ich denke, Motivation und Ausdauer sind die wichtigsten Ressourcen. Die meisten Leute werden nicht einmal in Betracht ziehen, in Google nach Sicherheitslücken zu suchen, weil sie die besten Ingenieure der Welt haben, aber sie zahlen jedes Jahr Millionen von Bug-Bounties aus. Ich arbeite seit über 2 Jahren an einem Ziel und jetzt fange ich an, zu den wirklich interessanten Bugs zu kommen. Es dauert eine Weile. Das Problem beim normalen Pentesting ist, dass die Tester einen bestimmten Betrag erhalten, unabhängig davon, ob sie kritische Sicherheitslücken finden oder nicht. Ich glaube, es gibt immer noch viele Bugs auf Facebook, es braucht nur jemanden, der bereit ist, tief genug zu graben.

Was war dein erster Gedanke, als du das Ausmaß des Ticket-Tricks erkannt hast?

Ich hatte gemischte Gefühle. Ich war erstaunt und dachte sofort an die Bug-Bounties, die ich damit sammeln könnte, aber auf der anderen Seite war ich schockiert, dass das möglich war. Immer wenn man so etwas findet, besitzt man plötzlich eine Menge wertvoller Informationen, an denen böswillige Parteien sehr interessiert wären. Der Offenlegungsprozess ist schwierig: Sie müssen so viele betroffene Unternehmen wie möglich informieren, aber auf der anderen Seite müssen Sie sicherstellen, dass die Informationen nicht durchsickern oder missbraucht werden.

Warum habt ihr beschlossen, die Informationen zu veröffentlichen, bevor ihr weitere Prämien kassiert?

Das Richtige zu tun ist wichtiger als Kopfgelder zu sammeln. Ich denke, ich hatte meinen fairen Anteil und möchte jetzt der Community etwas zurückgeben. Außerdem informiere ich Unternehmen seit Monaten über dieses Problem, sodass immer mehr Menschen davon wussten. Ich wollte nicht, dass es durchsickert oder von jemandem mit schlechten Absichten missbraucht wird.

Wie haben Sie die Antworten der betroffenen Unternehmen empfunden?

Die meisten Antworten waren zufriedenstellend. Einigen Unternehmen war das nicht wirklich wichtig, aber am Ende des Tages ist es ihr Verlust. Als Sicherheitsforscher abgelehnt zu werden, ist Teil des Spiels. Zumindest habe ich keine Klagen bekommen. Vor 10 Jahren wäre das wahrscheinlich der Fall gewesen.

Eine letzte Frage, auf Reddit habe ich gelesen, dass du 8.000$ an Bug-Bounties beansprucht hast. Hast du irgendwelche coolen Pläne, dieses Geld auszugeben?

Insgesamt habe ich durch diesen Bug mehr als 20.000$ bekommen. Mehr als die Hälfte davon entfällt auf Steuern. Den Rest gebe ich für normale Dinge wie Reisen aus, zum Abendessen ausgehen,... nichts Verrücktes. :-)

Vielen Dank für Ihre Zeit und viel Glück bei der zukünftigen Jagd!

Der Bug ist immer noch da draußen. Es ist nicht etwas, das sofort behoben werden kann. In den letzten Monaten habe ich im Rahmen ihrer Bug-Bounty-Programme Dutzende von Unternehmen und betroffenen Anbietern kontaktiert, um deren Konfiguration zu reparieren.

https://medium.freecodecamp.org/how-i-hacked-hundreds-of-companies-through-their-helpdesk-b7680ddc2d4c

A version of this article appeared in Dark Reading. It has been updated and syndicated here.

‍

If ever there was something to ruin Christmas in the cybersecurity industry, it’s a devastating data breach that is on track to becoming the largest cyberespionage event affecting the US government on record. 

The SolarWinds attack is far-reaching, with threat actors having initially breached the software as early as mid-2019. This months-long heist was discovered in December 2020 after it was used to infiltrate prominent cybersecurity firm, FireEye, and the nightmare unraveled from there. The full scope of the breach is still being investigated, but key areas of infiltration include US Departments of State, Homeland Security, Commerce, and the Treasury, in addition to the National Institute of Health. 

This incident is going to have ongoing aftershocks, but the sheer sophistication of it is fascinating. At a technical level, it is a multi-layered infiltration involving custom malicious tooling, backdoors, and cloaked code, far beyond the skill of script kiddies we so often see exploiting more obvious errors.

Code laundering at its worst

CrowdStrike has done more of their genius work in reverse-engineering the exploit, and detailing the findings for all to see. It has now come to light that SolarWinds was the victim of an infrastructure breach, allowing malicious code injection into system updates, resulting in at least four separate malware tools opening up unprecedented access for the threat actors.

The method was covert, allowing for a strategic precision that seems straight out of a Jason Bourne novel. It bought time to sniff around, plan, and strike victims outside of the SolarWinds network exactly when they wanted, in a comprehensive supply chain attack. And it was all carried out with code that looked completely benign. 

Cyberattacks are often the result of simple, yet costly, errors. And once discovered, the mistakes are fairly obvious; think a poorly configured network, passwords stored in plaintext, or unpatched software that sits vulnerable to known exploits. In this case, the code didn’t stand out at all, and not just to developers and security engineers. A wide myriad of expensive, complex security technology failed to detect it too.  

Security monitoring and penetration testing tools were rendered virtually useless

Security professionals tend to be as rare as rocking horse excrement, so they are aided in their quest to secure enormous amounts of company data, software, and infrastructure, by a technology stack that is customized to the security needs of the business. This usually takes the form of components like network firewalls, automated penetration testing, monitoring and scanning tools, with the latter soaking up a lot of time in the software development process. This tooling can quickly spiral and become unruly to manage and execute, with many companies using upwards of 300 different products and services.

SolarWinds would have an eye-watering array of tools to find and highlight security bugs in code, attempted unauthorized network access, potential compromise in any part of the infrastructure, and even pick up on signs of detection evasion. It is unprecedented that these threat actors were able to inject malicious code that went undiscovered even by the most advanced security stack. 

Infrastructure hardening - especially access control - are fundamental components of general cybersecurity best practice, but if an attacker can quietly exploit a tiny window of opportunity, then a network can be compromised just the same as a vulnerability in standalone software. 

This breach is a reminder that, in general, any company that relies heavily on tools alone to secure its network infrastructure and software is taking an enormous risk. It’s not always enough to protect code; everything storing, running, and compiling it must be equally as fortified. The ideal state is a balance of tools and people, executing a robust strategy that goes deep in assessing and reducing the potential attack surface.

Cross-team security awareness makes for better threat modeling

The SolarWinds breach has already started to make a significant impact on security operations, especially at a government level. Experts are touting that this could reshape cybersecurity practices forever.

An increasingly digital infrastructure powers our lives, and while it can be vulnerable to attack if not meticulously managed, our general strategy is flawed. We are wildly understaffed when it comes to security expertise, yet we’re not doing a whole lot to close the gap. Human-driven security awareness is an underutilized element of cybersecurity, as is making prevention - rather than reaction - a priority. 

Infrastructure security is a complex undertaking with many moving parts, but, similar to how they are positioned in software creation, developers can be an asset in reducing structural risk if properly trained and security-aware. 

Threat modeling rarely accounts for supply-chain attacks, despite this type of attack being highlighted as early as 2012 as a key risk that is difficult to prevent with current techniques, and it leaves many companies under-prepared. Software developers could absolutely play a role in prevention, and it starts with ensuring they are upskilled and able to assess their code integrity from the inside out. Have they built the update mechanism securely? Is the software running with unnecessary connectivity that could allow for easier malicious compromise? 

When security is synonymous with software quality, it is easy to see the immense value a security-aware engineer can bring to the table.

Entwickler stehen vor ständigen Herausforderungen, um ihre Fähigkeiten auf dem neuesten Stand zu halten und der Konkurrenz immer einen Schritt voraus zu sein. Angesichts des rasanten technologischen Fortschritts und der regelmäßigen Einführung neuer Tools und Frameworks war kontinuierliches Lernen noch nie so wichtig wie heute. In diesem digitalen Zeitalter, in dem Informationen jederzeit zur Verfügung stehen, können Entwickler das Potenzial von Lerninhalten auf Abruf nutzen, um ihre Karriere voranzutreiben und im wettbewerbsintensiven Bereich der Softwareentwicklung relevant zu bleiben.

Lerninhalte auf Abruf bieten Entwicklern mehrere wichtige Vorteile. On-Demand-Ressourcen bieten beispiellose Flexibilität und Komfort und ermöglichen es Entwicklern, in ihrem eigenen Tempo zu lernen und den Unterricht an ihren vollen Terminkalender und ihre persönlichen Vorlieben anzupassen. Darüber hinaus bieten agile Plattformen häufig gezielte Lernpfade, die auf individuelle Ziele und Qualifikationsniveaus zugeschnitten sind. So wird die Lerneffizienz maximiert und sichergestellt, dass Entwickler die Fähigkeiten erwerben, die sie für ihren beruflichen Aufstieg benötigen. Letztlich fördert On-Demand-Lernen eine Kultur der kontinuierlichen Kompetenzentwicklung, die es Entwicklern ermöglicht, angesichts des technologischen Wandels agil und widerstandsfähig zu bleiben und ihren langfristigen Erfolg im Bereich der Softwareentwicklung sicherzustellen.

‍

Bei Secure Code Warrior sind wir bestrebt, Entwicklern die umfassendsten und robustesten verfügbaren Inhalte zur Verfügung zu stellen. Unser Ziel ist es nicht nur, erstklassige Lern- und Entwicklungsressourcen anzubieten, sondern ihnen auch zur richtigen Zeit Informationen zur Verfügung zu stellen, die für die aktuellen Bedürfnisse der Entwickler relevant sind. Dieses Engagement kommt in unserem Tab „Erkunden“ zum Ausdruck, einer Inhaltsbibliothek innerhalb der SCW-Plattform, die darauf ausgelegt ist, die Herausforderung verstreuter Ressourcen zu bewältigen. Explore konsolidiert alle Schulungsinhalte an einem zentralen Ort und bietet Benutzern mühelos einen umfassenden Überblick über die verfügbaren Inhaltstypen. Ganz gleich, ob die Lernenden eine neue Programmiersprache beherrschen oder sich mit komplizierten Konzepten vertraut machen möchten, Explore bietet alles. Unser sorgfältig kuratierter Inhaltskatalog deckt eine Vielzahl von Interessen und Qualifikationsstufen ab und stellt sicher, dass für jeden etwas dabei ist. Mit Explore finden die Lernenden eine Fülle an interaktiven Tutorials, praktischen Übungen und realen Szenarien, die alle darauf ausgelegt sind, das Lernerlebnis zu verbessern und Entwicklern die Möglichkeit zu geben, herausragende Leistungen zu erbringen.

‍

‍

Technologische Ökosysteme sind heute durch ständige Innovation und Disruption gekennzeichnet, weshalb die Notwendigkeit agile Lernplattformen ist zunehmend kritischer geworden. Traditionelle Methoden des Lernens und der Entwicklung von Fähigkeiten reichen nicht mehr aus, um mit den rasanten technologischen Fortschritten und den dynamischen Anforderungen der Branche Schritt zu halten. Aus diesem Grund wenden sich Unternehmen agilen Lernplattformen zu, um Entwicklern die Tools und Ressourcen zur Verfügung zu stellen, die sie benötigen, um sich in diesem schnelllebigen Umfeld, in dem Entwickler tätig sind, anzupassen und erfolgreich zu sein getriebene Sicherheit ist unerlässlich.

Einer der Hauptgründe, warum agile Lernplattformen unverzichtbar sind, ist ihre Fähigkeit, zeitnahe und relevante Lerninhalte bereitzustellen. Agile Lernplattformen nutzen dynamische Mechanismen zur Bereitstellung von Inhalten wie Mikrolernmodule und Just-in-Time-Ressourcen, um Entwicklern genau dann das Wissen zur Verfügung zu stellen, das sie benötigen, und zwar genau dann, wenn sie es benötigen. Ein weiterer Schwerpunkt liegt auf ihrer Fähigkeit, Flexibilität und Anpassungsfähigkeit anzubieten, sodass Entwickler ihre Lernerfahrungen an ihre individuellen Bedürfnisse und Vorlieben anpassen können. Unabhängig davon, ob sie interaktive Tutorials, praktische Übungen oder Videoinhalte bevorzugen, können Entwickler das Format wählen, das am besten zu ihrem Lernstil und Zeitplan passt.

Alles in allem spielen agile Lernplattformen eine entscheidende Rolle dabei, Entwicklern zu ermöglichen, in der heutigen schnelllebigen und sich ständig verändernden Technologielandschaft erfolgreich zu sein. Durch die Bereitstellung zeitnaher, relevanter und personalisierter Lernerfahrungen ermöglichen diese Plattformen Entwicklern, neue Fähigkeiten zu erwerben, Branchentrends einen Schritt voraus zu sein und Innovationen in ihren Organisationen voranzutreiben. Bei Secure Code Warrior stehen Entwickler im Mittelpunkt, da wir unsere Plattform kontinuierlich verbessern. Wir verstehen die zentrale Rolle, die Entwickler bei der Entwicklung sicherer Software spielen, und stellen sicher, dass unsere Verbesserungen nicht nur aktuelle Herausforderungen bewältigen, sondern es Entwicklern auch ermöglichen, mit Zuversicht belastbaren Code zu erstellen. Hier sind einige der für Entwickler optimierten Plattformverbesserungen, die wir kürzlich implementiert haben, um dieses Engagement zu bekräftigen.

Wir glauben, dass wir Ihre Entwickler effektiver über moderne Kommunikationskanäle wie Microsoft Teams ansprechen können. Unsere Integration mit Microsoft Teams ist unser erster Schritt in Richtung Benutzerkommunikation der nächsten Generation innerhalb der SCW-Plattform. Laden Sie sie zu neuen Lernaktivitäten ein und senden Sie ihnen individuelle Erinnerungen an die Lernaktivitäten im Kurs. Sie können Teams auch als Übermittlungskanal für Nudges verwenden. Dort können Sie Kursteilnehmer per Teams-Benachrichtigung dazu bewegen, ihren Kurs abzuschließen.

‍

Zu unseren entwicklerorientierten Produktinnovationen gehört auch unser Tab Erkunden. Egal, ob Benutzer ihre Fähigkeiten verbessern oder in neue Bereiche eintauchen möchten, Explore sorgt für ein nahtloses und bereicherndes Entwicklererlebnis, indem es eine umfassende Plattform für Schulungen und Wissenserweiterungen im eigenen Tempo bietet. Explore bietet über 7.000 Aktivitäten in 64 Sprachen und ermöglicht es Benutzern, Lernaktivitäten, die auf ihre Vorlieben zugeschnitten sind, mühelos zu entdecken, zu spielen und erneut abzuspielen. Klicken Sie hier, um mehr über Explore zu erfahren und die Bedeutung von Content on Demand.

‍

Schließlich sind Berichte von entscheidender Bedeutung, um die Entwicklerschulung effektiv und ansprechend zu gestalten. Sie verfolgen nicht nur den Fortschritt und stellen die Einhaltung der Sicherheitsstandards sicher, sondern identifizieren auch Lücken, in denen Entwickler Verbesserungen vornehmen können. Diese Erkenntnisse ermöglichen maßgeschneiderte Schulungen, die die Sicherheitsmaßnahmen stärken und dafür sorgen, dass das Lernen relevant und zielgerichtet bleibt. Berichte helfen auch dabei, die Investition in Schulungen zu rechtfertigen, da sie deren Wirkung belegen und so die kontinuierliche Unterstützung von Sicherheitsinitiativen sicherstellen. Insgesamt sind Berichte ein unverzichtbares Instrument, um sowohl die Einhaltung von Vorschriften als auch das Engagement der Entwickler zu verbessern, damit alle Beteiligten auf dem Laufenden bleiben und sich auf ihren Lernprozess einlassen. Halten Sie Ausschau nach aufregenden Neuigkeiten rund um die SCW-Berichterstattung, die bald veröffentlicht werden!

‍

Um noch mehr über die kürzlich veröffentlichten Funktionen zu erfahren, schauen Sie sich unsere neuesten Produktgespräch, Webinar oder kontaktieren Sie uns noch heute!

‍

Im dynamischen Bereich der Softwareentwicklung ist Agilität nicht nur ein Schlagwort, sondern eine Notwendigkeit. Angesichts der sich ständig ändernden Landschaft müssen Entwickler eine Denkweise des kontinuierlichen Lernens annehmen, um die Mean Time to Remediation (MTTR) weiter zu optimieren. Agiles Lernen beinhaltet die Fähigkeit, sich schnell an neue Technologien, Methoden und Problemlösungstechniken rund um sicheres Programmieren anzupassen. In diesem Blog werden wir untersuchen, wie die Einführung von agilem Lernen zu einem entscheidenden Faktor bei der Reduzierung der MTTR und der Verbesserung der allgemeinen Entwicklungseffizienz werden kann.

Herausforderungen für Entwickler bei der Verkürzung der mittleren Zeit bis zur Problembehebung (MTTR)

Die mittlere Zeit zum Ausnutzen Sicherheitslücken im Jahr 2023 liegt bei 44 Tagen, aber 75% der Sicherheitslücken wurden innerhalb von 19 Tagen nach der Veröffentlichung ausgenutzt. Dies sollte als Weckruf für eine proaktive Haltung in Bezug auf Patch-Management, Bedrohungsinformationen und Schulung von Entwicklern dienen.

Entwickler stehen bei der Identifizierung und Lösung von Problemen vor einer Reihe von Herausforderungen, die auf das komplizierte Netz von Tools und Systemen, Kommunikationslücken und mangelnde Fähigkeiten zurückzuführen sind, um ein Problem zu lösen, das sofortige Aufmerksamkeit erfordert. Im Folgenden finden Sie einige der Herausforderungen, mit denen Entwickler bei der Behebung einer Sicherheitslücke konfrontiert sind.

Komplexität der Systeme und mangelnde Automatisierung:

• Moderne Anwendungen bestehen häufig aus Microservices, APIs und verschiedenen Integrationen von Drittanbietern. Die Identifizierung der Grundursache eines Problems in solch komplexen Systemen kann schwierig und zeitaufwändig sein. Manuelle Prozesse zur Problemerkennung, -analyse und -lösung können zeitaufwändig sein. Mangelnde Automatisierung kann die Geschwindigkeit beeinträchtigen, mit der Entwickler auf Vorfälle reagieren können.

Eingeschränkte Sichtbarkeit und Kommunikation:

• Entwickler sehen sich mit vielen Schwierigkeiten konfrontiert, wenn es darum geht, in Echtzeit Einblicke in das Systemverhalten und die Leistung zu erhalten. Dies kann ihre Fähigkeit beeinträchtigen, Probleme schnell zu identifizieren und zu beheben.
• Eine effiziente Kommunikation ist für die Problemlösung von entscheidender Bedeutung. Isolierte Kommunikationskanäle und mangelnde Zusammenarbeit zwischen Entwicklungs-, Betriebs- und anderen Teams können zu Verzögerungen bei der Problemlösung führen.

Mangelnde Fähigkeiten, um ein Problem schnell zu beheben:

• Ohne ein angemessenes Verständnis der sicheren Codierungspraktiken können Entwickler Schwierigkeiten haben, effektive Patches anzuwenden, ungewollt neue Fehler einzuführen und wichtige Sicherheitskontrollen zu übersehen. Dieses Unverständnis kann die Zusammenarbeit mit Sicherheitsexperten behindern und zu unvollständigen oder ineffektiven Korrekturen führen, was das Risiko von Sicherheitsbedrohungen in der Codebasis erhöht.

Der Vorteil des agilen Lernens

Agile Lernende sind geschickt darin, neue Fähigkeiten zu erwerben. Da sich Technologien weiterentwickeln und Systeme immer komplexer werden, müssen Entwickler ihrer Zeit immer einen Schritt voraus sein. Die Investition in eine Plattform für kontinuierliches Lernen wird das Team mit den neuesten Fehlerbehebungs- und Debugging-Techniken ausstatten.

1. Adaptive Problemlösung

Agile Lernende gedeihen in Umgebungen, in denen Problemlösung ein iterativer Prozess ist. Durch die Förderung einer Kultur, die zum Experimentieren und Lernen aus Misserfolgen ermutigt, können Entwicklungsteams ihre Fähigkeit verbessern, komplexe Probleme umgehend anzugehen.

2. Funktionsübergreifende Zusammenarbeit

Agiles Lernen geht Hand in Hand mit funktionsübergreifender Zusammenarbeit. Entwickler, Sicherheitsteams und andere Teams müssen nicht nur Wissen austauschen, sondern auch gemeinsam aus den Erfahrungen der anderen lernen. Diese kollaborative Denkweise beschleunigt die Problemlösung, indem ein breites Spektrum an Fähigkeiten und Perspektiven genutzt wird.

3. Integrieren Sie das Lernen in den Entwickler-Workflow:

Implementieren Sie kurze, fokussierte Lernsprints innerhalb des Entwicklungszyklus. Diese Sprints können der Erforschung neuer Technologien, Tools oder Problemlösungsmethoden gewidmet sein. Indem Teams Zeit für kontinuierliches Lernen einplanen, können sie proaktiv die Fähigkeiten erwerben, die zur Bewältigung neuer Herausforderungen erforderlich sind.

4. Multiplikation der Sicherheitschampions:

Fördern Sie eine Sicherheitskultur innerhalb des Teams, an deren Spitze erfahrene Entwickler stehen. Sie können weniger erfahrene Teammitglieder anleiten, ihr Wissen weitergeben und wertvolle Erkenntnisse liefern. Dieses Mentoring beschleunigt nicht nur die Lernkurve, sondern bringt auch mehr Sicherheitsexperten hervor.

Unter Berücksichtigung dieser Kernprinzipien konnten die Kunden von Secure Code Warrior erhebliche Fortschritte bei der Verbesserung der mittleren Zeit bis zur Problembehebung verzeichnen. Dies kann in Tagen gemessen werden, wobei bei einem Kunden eine Verkürzung der Reparaturdauer um 150 Tage zu verzeichnen war. Oder es kann innerhalb der Zeit gemessen werden, bis das Problem behoben ist. Erfahren Sie zum Beispiel, wie Sage mit Secure Code Warrior die Zeit eines Teams zur Behebung von Problemen um 82% reduziert hat.

Fazit

Wenn es um die Optimierung von MTTR geht, erweist sich agiles Lernen für sicheren Code als Katalysator für kontinuierliche Verbesserungen bei der Behebung hartnäckiger Sicherheitslücken. Durch die Etablierung einer Kultur, die Anpassungsfähigkeit wertschätzt, kontinuierliches Lernen fördert und funktionsübergreifende Zusammenarbeit erleichtert, können Entwicklungsteams die Herausforderungen der sich ständig weiterentwickelnden Softwarelandschaft nicht nur bewältigen, sondern auch übertreffen. Lassen Sie sich bei der Bewältigung der Komplexität von Softwaresystemen von agilem Lernen als Kompass leiten, der Entwickler zu schnelleren Problemlösungen und nachhaltigem Erfolg führt.

‍