Da unsere immer ausgefeiltere Technologie immer mehr vernetzte Systeme hervorbringt, wird die Notwendigkeit einer größeren Sicherheit wichtiger denn je. Doch Cybersicherheit ist nicht mehr gleichbedeutend mit der Einrichtung einer Firewall oder einer Antivirensoftware. Es ist ein Prozess, der Richtlinien, Schulungen, Compliance, Risikobewertung und Infrastruktur umfasst. Wenn dieser Prozess nicht vorhanden ist, kann dies zu erheblichen Datenverlusten und Rufschädigung führen.
In diesem Artikel stelle ich Ihnen das Konzept des White Hat Hacking vor und zeige Ihnen, wie es mir gelungen ist, über einen ungesicherten und veralteten Jira-Rechner auf ein AWS-Konto zuzugreifen.
Lassen Sie uns also gleich eintauchen!
Weiße Hüte gegen schwarze Hüte
Der Trick, um alle Bereiche abzudecken
Die Notwendigkeit einer soliden Sicherheit gilt insbesondere für Cloud-Lösungen, da Ihre Daten ständig von einem Punkt zum anderen fließen. Wenn sie nicht richtig gesichert sind, können diese Daten auf ihrem Weg von Endpunkt zu Endpunkt für Angriffe anfällig sein.
Es gibt Leute, die nicht nur Ihre Website, Ihre Kommunikation und Ihre Anwendungen stören wollen, um sich einen finanziellen Vorteil zu verschaffen, sondern auch, um Ihren Ruf zu schädigen. Sie operieren im Dunkeln, abseits des Mainstreams, und sind darauf spezialisiert, Schlupflöcher und Schwachstellen auszunutzen.
Die Millionen-Dollar-Frage lautet also: Wo sind die Schwachstellen in Ihren Systemen?
Der CISO der Société Générale, Stephane Nappo, sagte einmal, dass "eines der größten Cyber-Risiken darin besteht, zu glauben, dass es sie nicht gibt." Es kann in der Tat schwierig sein, die Sicherheitsbedrohung mit herkömmlichen Testmethoden wie Unit-Tests, Integrationstests, Smoke-Tests und Regressionstests zu identifizieren.
In den meisten Fällen schaffen es diese Tests - die in der Regel innerhalb Ihres Unternehmens durchgeführt werden - nicht immer, die Bedingungen realistisch zu gestalten, die für jemanden bestehen, der von außerhalb Ihres Unternehmens einsteigen möchte.
Es braucht einen Dieb, um einen Dieb zu fangen, sagt das alte Sprichwort. Das gilt auch für den digitalen Bereich. In Verbindung mit einer soliden Sicherheitsstrategie bildet dieses Prinzip die Grundlage für ethisches Hacking, auch White Hat Hacking genannt.
Was ist White Hat Hacking?
Entgegen der landläufigen Meinung sind Hacker nicht immer bösartig!
Wir unterscheiden im Allgemeinen zwischen Black Hat- und White Hat-Hackern, die in der Regel über ein umfassendes Wissen über das Eindringen in Computersysteme und die Umgehung von Sicherheitsprotokollen verfügen. Der Unterschied liegt in der Absicht.
Ein White Hat Hacker ist ein Sicherheitsexperte, der Sicherheitsrisiken in einer Software aufdeckt, die er dann dem Eigentümer meldet, damit dieser die entsprechenden Sicherheitsmaßnahmen ergreift; ein White Hat Hacker arbeitet immer mit guten Absichten.
Was genau sind diese Absichten? Die allgemeine Sicherheit Ihrer Systeme erhöhen
Und dann gibt es noch die Hacker, die wir alle aus den Filmen kennen: Black Hat Hacker. Das sind Sicherheitsexperten, die beabsichtigen, aufgedeckte Sicherheitslücken auszunutzen, um selbst davon zu profitieren - natürlich ohne vorherige Zustimmung des Systembesitzers. Ihr primäres Ziel ist es, zu erpressen, den Ruf zu zerstören und andere ruchlose Dinge zu tun - ich bin sicher, Sie haben die Schlagzeilen gesehen.
Ein wichtiger Teil des QA-Prozesses
Es ist ein Katz-und-Maus-Spiel: Weiße Hüte versuchen, Systemschwachstellen aufzudecken und sie zu beheben, bevor schwarze Hüte sie ausnutzen können.
Externes White Hat Hacking sollte ein wesentlicher Bestandteil des QA-Prozesses eines Unternehmens sein, denn es schließt eine Lücke, die interne Penetrationstester nicht schließen können - selbst wenn realistische Umstände simuliert werden. Das liegt daran, dass sie in der Regel innerhalb eines bestimmten Rahmens arbeiten, bestimmte Aufgaben erhalten und - was am wichtigsten ist - oft nicht persönlich motiviert sind, wirklich tief zu graben.
In meiner Rolle als Sicherheitsforscher setze ich oft den alten weißen Hut auf und durchsuche das Internet nach anfälliger Software. Bei meiner Suche finde ich genau das - falsch konfigurierte Rechner. Der Trick besteht darin, den Besitzer eines bestimmten Rechners zu finden. Das ist die zentrale Herausforderung, die ich - ähnlich wie meine Kollegen, die Black Hat Hacker - zu lösen versuche.
Der CTO eines der Unternehmen, dem ich geholfen habe, bestimmte Sicherheitslücken zu schließen, hat es so formuliert:
"Es ist, als ob Sie über ein Haus mit offener Tür stolpern, hinein gehen, um zu sehen, was drin ist, ein Foto des Besitzers finden und ihn dann anrufen und sagen: "Hey, Ihre Sachen sind in Gefahr".
Wenn Sie Penetrationstests innerhalb eines Unternehmens durchführen, melden Sie in der Regel nur Schwachstellen, ohne die Anmeldedaten zu überprüfen, denn Sie wissen, wem das Haus gehört. Doch genau das ist es, was Black Hat Hacker tun - ihr primäres Ziel ist ihnen anfangs oft unbekannt. Sie werden alles versuchen, um Anmeldeinformationen zu finden. Und wenn sie diese finden, können sie anfangen, Profit zu machen.
Wie ich schon sagte, man braucht einen, um einen zu kennen!
Wie ich mich in ein AWS-Konto gehackt habe
Cyber Cold Case oder aktuelles Risiko?
Auf meinem Weg, mehr über die effektive Absicherung von Cloud-Lösungen zu erfahren, führe ich manchmal Penetrationstests durch, um zu sehen, wie sicher eine bestimmte Software ist. Normalerweise finde ich interessante Themen im Cyber Security Subreddit und im Exploit db und beschließe dann, etwas genauer zu erforschen.
Bei einem kürzlichen "Aufklärungsangriff" bin ich einige alte Sicherheitslücken in Atlassian Software durchgegangen, die bereits 2018 aufgedeckt wurden, um zu sehen, ob einige Unternehmen noch anfällig sind. Damals, im Jahr 2018, war dieser Fehler ziemlich weit verbreitet und viele Unternehmen bemühten sich, diese Sicherheitslücke zu schließen - aber nicht alle, wie sich herausstellte.
Ich begann damit, das Internet mit Hilfe von Suchmaschinen wie Shodan, Censys oder BinaryEdge zu durchsuchen, die Antworten von verschiedenen Ports auf allen IPs indizieren und das Internet ständig auf Sicherheitslücken überwachen. Bei meiner Suche fand ich mehrere Rechner, auf denen veraltete Jira-Software lief.
Die Sache mit Jira-Versionen unter v7.3.5 ist, dass sie einen anfälligen offenen Proxy enthalten, der anonym verwendet werden kann, um beliebige Daten aus internen Netzwerken zurückzugeben.
Nehmen wir an, der Jira-Server arbeitet unter der folgenden Adresse:
https://example.com/secure/Dashboard.jspa
Ich wusste also, dass Jira in dieser Version den Fehler enthielt, aber nur um sicherzugehen, habe ich das verwundbare Plugin überprüft, um zu bestätigen, dass die Schwachstelle auf diesem Rechner noch vorhanden war. Und das tat sie!
Proof of Concept - Ich habe versucht, google.com unter der Domain example.com zu öffnen:
https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://google.com
Dann vergewisserte ich mich, dass der Rechner auf AWS lief, indem ich den DNS-Namen überprüfte. Es hieß, dass diese IP zu einer EC2-Instanz auf AWS gehört. Ich war also auf dem richtigen Weg - und begab mich auf vertrautes Terrain.
Ein bisschen tiefer graben
Nun weiß ich, dass eine EC2-Instanz die lokale Adresse nach Benutzerdaten und Metadaten abfragen kann.
Benutzerdaten sind das Skript, das der Benutzer dem Rechner zur Verfügung stellt, damit es beim Start des Rechners ausgeführt wird. Die Benutzerdaten enthalten manchmal sensible Informationen.
Metadaten hingegen enthalten Details der EC2-Instanz wie AWS-Region, Availability Zone, SSH-Schlüsselname - und wenn eine IAM-Rolle angehängt ist, können Sie sogar temporäre Anmeldedaten extrahieren! Die EC2-Instanz erzeugt diese temporären Anmeldeinformationen, um mit anderen AWS-Diensten zu kommunizieren. Sie können sie extrahieren und von Ihrem lokalen Rechner aus verwenden.
Das habe ich also getan! Ich habe einfach nach den EC2-Metadaten gefragt.
https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/
Der Sache auf den Grund gehen
Je nach den Richtlinien, die von der an die EC2-Instanz angehängten Rolle verwendet werden, können Sie unterschiedliche Dinge damit tun. Wenn eine bestimmte Rolle nur das Senden von Protokollen an CloudWatch zulässt, können Sie CloudWatch zum Beispiel mit seltsamen Daten überfluten, um es zu verwirren und einen Neustart der Instanz zu erzwingen oder eine automatische Skalierung zu veranlassen.
Aber manchmal macht man den Fehler, das Prinzip des geringsten Privilegs nicht zu befolgen, d.h. einer Rolle nur so viel Zugang zu Informationen zu gewähren, wie sie benötigt, um ihre Aufgabe erfüllen zu können.
Es könnte also sein, dass eine bestimmte Rolle mit der Richtlinie AdministratorAccess verknüpft ist, und dann kann die JIRA-Instanz für so ziemlich alles verwendet werden: Ressourcen erstellen, Ressourcen ändern, Ressourcen beenden, verschlüsseln, entschlüsseln, auf Abrechnungsdetails zugreifen, usw.
Die Metadaten geben einen "iam/"-Endpunkt zurück, der nur verfügbar ist, wenn der Instanz eine Rolle zugeordnet ist.
Durch die Abfrage der temporären Rollenzugangsdaten erhielt ich einen neuen AWS-Zugang, geheime Schlüssel und ein Session-Token:
https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/iam/security-credentials/EXT-JIRA-SERVER-1-ROLE
Es ist auch gut, die Region zu kennen, in der die Ressourcen erstellt wurden, denn sie ist erforderlich, wenn Sie AWS CLI verwenden möchten. Dies kann auch aus den Metadaten entnommen werden:
https://example.com/plugins/servlet/oauth/users/icon-uri?consumerUri=http://169.254.169.254/latest/meta-data/placement/availability-zone
Mit all diesen Informationen können Sie mit AWS CLI prüfen, welche Aktionen mit dieser Rolle möglich sind.
Mein Skript fragte zunächst einfach nach der Liste der S3-Buckets, der Liste der IAM-Benutzer und den Abrechnungsinformationen des letzten Monats.
Alle Anfragen waren erfolgreich. Das bedeutet in der Regel, dass die Rolle mit einer AdministratorAccess-Richtlinie verknüpft ist, da normalerweise nur Administratoren auf die Abrechnung zugreifen können.
Um den Besitzer zu identifizieren, habe ich zusätzlich nach AWS-Organisationsdetails und Route53-Domänen gefragt.
Schelmische Taten und wie man sie vermeidet
Wie bereits erwähnt, können Sie über den Jira Rechner auf das interne Netzwerk zugreifen, in dem er sich befindet. Alle privaten gehosteten Zonen (example.local) stehen Ihnen ebenfalls offen.
Die verschiedenen Atlassian-Anwendungen, die möglicherweise nur im internen Netzwerk laufen - wie Confluence oder BitBucket - sind jetzt für mich zugänglich. Manchmal war sogar keine Anmeldung erforderlich, weil es sich um eine lokale Ressource handelte, und da ich von Jira aus darauf zugreife, denkt das System, ich befände mich im internen Netzwerk.
Mit dieser Art von Zugang könnte ein Black Hat Hacker:
- einen IAM-Benutzer für sich selbst anlegen,
- zusätzliche Zugangsschlüssel für bestehende Benutzer erstellen,
- Admin-Rollen an andere gefährdete Dienste anhängen,
- Objekte aus S3-Buckets kopieren,
- AMIs von laufenden Instanzen erstellen und neue Instanzen mit seinen Schlüsseln starten, um sich anzumelden,
- AMIs mit anderen AWS-Konten teilen,
- löschen Sie alles aus dem Konto,
- die AWS-Organisation verlassen,
- CloudTrail-Protokolle entfernen,
- und mehr...
Die obige Liste veranschaulicht die vielen Möglichkeiten, die ein Black Hat Hacker hat, um Ihr AWS-Konto zu manipulieren. Was ist also in diesem Beispiel schief gelaufen?
- Verletzung des Prinzips der geringsten Rechte - Jeder Benutzer, jedes Programm und jeder Prozess sollte nur über das absolute Minimum an Rechten verfügen, um seine Funktion erfüllen zu können. In diesem Fall erhielt der EC2 durch die ihm zugewiesene Administratorrolle unbegrenzte Privilegien.
- Veraltete Software - Software-Updates können neue oder verbesserte Funktionen und eine bessere Kompatibilität mit anderen Geräten und Anwendungen enthalten. Aber noch wichtiger ist, dass sie auch Sicherheitskorrekturen bieten. In diesem Fall war es eine bekannte Sicherheitslücke aus dem Jahr 2018, die es ermöglichte, die sensiblen Daten so einfach zu extrahieren. Atlassian hat die Sicherheitslücke schon vor langer Zeit geschlossen, aber Benutzer, die ihre Anwendungen nicht gepatcht haben, sind immer noch anfällig.
Anfällige Anwendungen & Versionen:
- Bamboo < 6.0.0
- Confluence < 6.1.3
- Jira < 7.3.5
- Bitbucket < 4.14.4
- Crowd < 2.11.2
- Tiegel & Fischauge < 4.3.2
Gut ausgegebenes, aber nicht gut gesichertes Geld
Auf der langen Liste der durchgesickerten Zugangsschlüssel, die ich gefunden habe. Einige verschafften mir Zugang zu Konten, die fast 100.000 Dollar pro Monat für AWS ausgeben.
Hier finden Sie eine Aufschlüsselung der entstandenen Kosten, die den Rechnungsdaten entnommen wurde:
Monatliche Ausgaben für AWS in $
- AWS CloudTrail: 0.00
- AWS Konfig: 66.92
- AWS Direktverbindung: 25.25
- AWS Kleber: 0.00
- AWS IoT: 0.00
- AWS Key Management Service: 45.80
- AWS Lambda: 298,20
- AWS Secrets Manager: 0.00
- Amazon DynamoDB: 24.94
- Amazon EC2 Container Registry (ECR): 0.06
- Amazon EC2 Container Service: 0.00
- Amazon ElastiCache: 1,041.44
- EC2 - Sonstiges: 6976.19
- Amazon Elastic Compute Cloud - Rechenleistung: 61.008,41
- Amazon Elastic File System: 3.61
- Amazon Elastic Load Balancing: 2,020.69
- Amazon Elasticsearch Service: 1.686,58
- Amazon Kinesis: 145.08
- Amazon Relationaler Datenbankdienst: 2.270,92
- Amazon Route 53: 1,148.44
- Amazon Einfacher E-Mail-Dienst: 2.67
- Amazon Einfacher Benachrichtigungsdienst: 0.01
- Amazon Simple Queue Service: 0.00
- Amazon Simple Storage Service: 1.770,76
- Amazon SimpleDB: 0.00
- Amazon Translate: 0.08
- Amazon Virtual Private Cloud: 559.91
- Amazon CloudWatch: 345.10
- Steuer: 7.673,75
- MONATLICHE GESAMTAUSGABEN FÜR AWS: $87,114.84
Wie Sie sehen können, nutzt dieses Unternehmen eine Menge AWS-Ressourcen. Ihre Sicherheitsmaßnahmen könnten jedoch definitiv verbessert werden!
Finden Sie die Eigentümer
Um die verantwortliche Organisation ausfindig zu machen, können Sie auf verschiedene Weise vorgehen. Hier sind einige Methoden, die ich häufig verwende, um Identitäten zu finden.
- Domainname aus SSL-Zertifikat
- Domains aus von Route53 gehosteten Zonen
- Domainnamen aus der Liste der S3-Buckets
- E-Mail-Adressen auf der Liste der IAM-Benutzer
- Vorname, Nachname aus der IAM-Benutzerliste -> LinkedIn
- URLs/Logos auf der Jira-Anmeldeseite
- AWS-Organisation Hauptzahlerkonto Stamm-E-Mail
- AWS-Konto Stammbenutzer E-Mail
- Verantwortliche Offenlegungs-E-Mail-Adresse von der Kontaktseite
- Datenschutz-E-Mail-Adresse von der Seite Datenschutz
Zusammenfassung
Nachdem ich die Besitzer des Jira-Rechners ausfindig gemacht hatte, setzte ich mich mit ihnen in Verbindung, um sie über die Sicherheitslücke in ihrem System zu informieren. Sie sagten, dass meine Entdeckung sie wirklich schockierte und die Sicherheitslücke sofort behoben wurde.
Sie sagten auch, dass sie einige Änderungen an ihren Cloud-Sicherheitsrichtlinien vornehmen und ihr Zugriffsmanagement neu bewerten würden.
Es ist eine gute Praxis, sich bei der Person, die für die Veröffentlichung des Fehlers verantwortlich ist, mit einem Bug Bounty zu bedanken - einer Belohnung, die ein Sicherheitsforscher für das Aufzeigen von Sicherheitsproblemen erhält. Es motiviert den Forscher, seine Arbeit fortzusetzen und Unternehmen bei der Schaffung strengerer Sicherheitsprozesse zu unterstützen.
Leider gab es diesmal kein Kopfgeld auf Fehler!
Was können Sie also tun, um zu vermeiden, dass Ihre Daten auf die oben beschriebene Weise preisgegeben werden?
- Wenden Sie das Prinzip der geringsten Privilegien an - Dies würde das Risiko eines unbefugten Zugriffs auf kritische Systeme oder sensible Daten über niedrigstufige Benutzerkonten, Geräte oder Anwendungen verringern.
- Aktualisieren Sie Ihre Software regelmäßig - Neben neuen Funktionen und größerer Kompatibilität ist die Verbesserung der Sicherheit ein wichtiger Bestandteil von Software-Updates.
In diesem Sinne möchte ich Sie mit einem weiteren Zitat verlassen. Diesmal von dem großen amerikanischen Schriftsteller Henry David Thoreau, direkt aus seinem Opus magnum, Walden.
"Wenn Sie Luftschlösser gebaut haben, brauchen Sie Ihre Arbeit nicht zu verlieren; dort sollten sie stehen. Jetzt legen Sie das Fundament darunter."
Mehr aus dieser Serie über das Hacken eines AWS-Kontos
Unsere Ideen
Weitere Blogs
Contact