Connect with us

Entwicklung & Code

Kommentar: Photoshop per KI nachgebaut – Kopieren ist billig, Entscheiden nicht


Anfang Oktober hat der Entwickler Brandon Thomas unter dem Projektnamen ArtCraft sieben Programme veröffentlicht, die Adobes bekannteste Werkzeuge nachbilden, darunter Photoshop, Lightroom und Premiere Pro.

Weiterlesen nach der Anzeige

Mittlerweile sind es 13 Anwendungen. Geschrieben sind sie in Rust, den Code hat im Wesentlichen Claude Opus 5.5 erzeugt, das aktuelle Spitzenmodell von Anthropic. Allein der Photoshop-Nachbau PhotoCraft sammelte auf GitHub binnen weniger Tage Zehntausende Sterne, und Thomas selbst brachte das Projekt auf Reddit auf eine Formel, die seitdem durch die Fachpresse wandert: „Software is over“.

Damit bekommt ein Abgesang neue Nahrung, der seit dem Aufkommen von Coding-Agenten ohnehin in schöner Regelmäßigkeit angestimmt wird. Wenn eine einzelne Person mit einem Sprachmodell Photoshop nachbauen kann, so die Logik, wozu braucht es dann noch Entwicklerinnen und Entwickler? Ich halte diesen Schluss für falsch, und ich halte das Vorgehen dahinter für verkehrt. Nicht die KI beendet die Softwareentwicklung. Das erledigen wir selbst, indem wir ihre Arbeit entwerten.

Was tatsächlich entstanden ist

Zunächst lohnt ein nüchterner Blick darauf, was PhotoCraft eigentlich ist. Das Projekt beschreibt sich in seiner README als quelloffene Clean-Room-Neuimplementierung von Photoshop, also als Nachbau, der ohne Zugriff auf den Originalcode entstanden sein soll. Grundlage seien öffentliche Spezifikationen und das beobachtete Verhalten des Originals. Mehr als 1700 Tests sichern das Ergebnis ab, und ein Teil davon vergleicht das, was PhotoCraft rendert, unmittelbar mit dem Bild, das Photoshop selbst aus derselben Datei erzeugt. Dieser Punkt wird gleich noch wichtig.


the next big thing – Golo Roden

the next big thing – Golo Roden

Golo Roden ist Gründer und CTO von the native web GmbH. Er beschäftigt sich mit der Konzeption und Entwicklung von Web- und Cloud-Anwendungen sowie -APIs, mit einem Schwerpunkt auf Event-getriebenen und Service-basierten verteilten Architekturen. Sein Leitsatz lautet, dass Softwareentwicklung kein Selbstzweck ist, sondern immer einer zugrundeliegenden Fachlichkeit folgen muss.

Neben dem Ende der Software kündigte Thomas auf Reddit auch an, binnen eines Monats vollständige Funktionsgleichheit mit Adobe zu erreichen. Auf Hacker News korrigierte er das später: 99 Prozent würden eine Weile dauern, sich aber in Monaten messen lassen, nicht in Jahren. Das Bildbearbeitungsmagazin DOCMA hat diese Aussagen neben den Fahrplan des Projekts gelegt und das Ergebnis in einer Überschrift zusammengefasst: Ein Monat, sagt der Entwickler, viele Monate, sagt sein eigener Fahrplan.

Weiterlesen nach der Anzeige

Aufschlussreicher als alle Ankündigungen ist ohnehin, was das Projekt über sich selbst sagt. Die README stellt ausdrücklich klar, dass PhotoCraft noch kein Ersatz für Photoshop im professionellen Alltag ist. Dass jeder Menüpunkt von Photoshop mit einem Befehl verbunden sei, messe lediglich die Verdrahtung, nicht das Verhalten.

Die Paritätsbewertung des Projekts schätzt Mitte Oktober, dass PhotoCraft zu etwa 45 Prozent für echte Arbeit taugt, und veranschlagt bis zur vollen Gleichwertigkeit weitere 2300 bis 4100 Stunden Agentenarbeit. Bis Mitte Oktober waren in dem Repository bereits rund 2400 Commits zusammengekommen. Diese Zahlen stammen nicht von Kritikerinnen und Kritikern, sondern aus dem Projekt selbst, und mit „Software is over“ haben sie wenig zu tun.

Den Anlass für das Ganze hat Thomas übrigens ebenfalls genannt: Er sei zu oft über Adobes Kündigungsgebühr gestolpert. Diesen Ärger können vermutlich viele nachvollziehen. An der Bewertung ändert er allerdings nichts.

Der Idealfall für Agenten

Bevor ich zu meiner Kritik komme, will ich einräumen, was das Projekt tatsächlich belegt. In Werkzeugwahl, Teil 1 habe ich vor wenigen Wochen geschrieben, dass Agenten dort stark sind, wo sich ihr Ergebnis deterministisch prüfen lässt: durch Tests und, wo Tests an Grenzen stoßen, durch den Compiler. PhotoCraft bestätigt das, und zwar in Rust, also in genau der Kombination aus strengem Compiler und umfangreicher Testsuite, um die es damals ging.

Allerdings hat der Fall eine Besonderheit, die ihn zum Idealfall macht. Das Beste, was es zum Prüfen geben kann, ist ein Ziel, das bereits exakt vorliegt. Photoshop ist seit 1990 auf dem Markt. Sein Verhalten lässt sich in jeder Situation beobachten, sein Dateiformat ist öffentlich spezifiziert, und für jede Frage, wie ein Bild nach einem bestimmten Arbeitsschritt aussehen muss, liefert das Original die richtige Antwort gleich mit.

Wer unter diesen Bedingungen arbeitet, muss an keiner Stelle entscheiden, was richtig ist. Er muss nur feststellen, ob das Ergebnis dem Original entspricht, und diese Aufgabe lässt sich hervorragend automatisieren. Genau deshalb kommen Agenten mit ihr so gut zurecht, und genau deshalb ist sie so wenig repräsentativ. Was sagt dieser Idealfall also über den Normalfall aus? Meine Antwort darauf: fast nichts.

Abgeschaut ist nicht entschieden

Software besteht nicht nur aus Code. In einem Programm wie Photoshop stecken mehr als drei Jahrzehnte an Entscheidungen. Wie sind die Arbeitsabläufe aufgebaut? Welche Werkzeuge gibt es und wie verhalten sie sich? Wie wird ein Problem aus Sicht derjenigen gelöst, die täglich damit arbeiten? Über all das haben Menschen nachgedacht, sie haben Varianten ausprobiert, verworfen und verbessert. Ein Nachbau übernimmt diese Entscheidungen, ohne eine einzige davon selbst treffen zu müssen.

Wie viel Arbeit in solchen Entscheidungen steckt, zeigt schon ein unscheinbares Beispiel. Dashboards gibt es zu Tausenden, das Prinzip ist hinlänglich bekannt. Trotzdem müssen Entwicklerinnen und Entwickler für jedes konkrete Produkt neu entscheiden, welche Daten ein Dashboard anzeigt und in welcher Form, wie sich auf einen Blick erkennen lässt, was gerade relevant ist, und wie möglichst viele Informationen sichtbar bleiben, ohne dass das Ganze überladen wirkt.

Eine allgemeingültige Antwort auf diese Fragen gibt es nicht, nur eine, die zum jeweiligen Produkt passt. Sie zu finden ist Arbeit, auch wenn das fertige Ergebnis sie später nicht mehr verrät. Und wer ein gelungenes Dashboard nachbaut, übernimmt genau diese Arbeit, ohne sie je geleistet zu haben.

Noch deutlicher wird das in Bereichen, die von außen kaum jemand wahrnimmt. Wir arbeiten seit mehr als zehn Jahren mit Druckereien zusammen, für Bücher, Broschüren, T-Shirts und manches andere. Allein bei Farben und Schriften kann dabei so viel schiefgehen, dass es sich niemand vorstellen kann, der es nie selbst erlebt hat. Die Programme von Adobe bieten für den Austausch mit Druckereien eine Fülle von Optionen, von denen viele andere Grafikprogramme nicht einmal ansatzweise etwas wissen.

PhotoCraft gibt an, CMYK-Dokumente und ICC-Farbmanagement zu unterstützen, einschließlich Softproof, also einer Vorschau darauf, wie ein Bild später im Druck aussehen wird. Ob das im Austausch mit einer echten Druckerei trägt, sei dahingestellt. Die README nennt die Tiefe bei Typografie und bei professionellen Arbeitsabläufen selbst als eine der größten Lücken, und laut der Lückenliste des Projekts weicht das Ergebnis bei gut einem Viertel der Referenzdateien, die Photoshop erzeugt hat, noch vom Original ab. Und selbst wenn eines Tages alles funktionieren sollte, wäre es das Ergebnis von Entscheidungen, die bei Adobe getroffen wurden.

Und wo es keine Vorlage gibt?

Der eigentliche Denkfehler hinter „Software is over“ liegt aber an anderer Stelle. Photoshop ist Standardsoftware: ein Produkt, das in identischer Form an Millionen Kundinnen und Kunden geht und dessen Verhalten alle beobachten können. Der größte Teil der Software, die tagtäglich entwickelt wird, sieht anders aus. Sie entsteht für eine bestimmte Branche, für eine Behörde oder für ein einzelnes Unternehmen, und es gibt sie nirgendwo, bevor jemand sie baut.

Ein Beispiel aus unserer eigenen Arbeit: In den vergangenen zweieinhalb Jahren haben wir für einen großen Energieversorger Software mit entworfen und mitentwickelt. Wo hätten wir die abschauen sollen? Bei einem anderen Energieversorger? Für die Versorgungswirtschaft gibt es zwar Standardsoftware, doch sie bildet gerade das nicht ab, was dieses Projekt ausgemacht hat, nämlich wie die Fachabteilung tatsächlich arbeitet, welche internen Prozesse über die Jahre gewachsen sind und welche UI- und UX-Standards das Unternehmen für alles vorgibt, was nach außen sichtbar ist.

Nichts davon lag als Vorlage bereit, gegen die sich ein Agent hätte testen lassen. All das musste erst verstanden werden, bevor sich auch nur eine Zeile Code sinnvoll schreiben ließ. Es gab kein Original, das für jeden Testfall die richtige Antwort liefert, sondern nur Menschen, die ihre Arbeit erklären, und Entscheidungen, die jemand treffen musste. Für die Fachanwendung einer Versicherung, das Fachverfahren einer Kommune oder die Steuerung einer Produktionslinie gilt nichts anderes.

In Der wahre Engpass habe ich beschrieben, dass der Flaschenhals in der Softwareentwicklung nie das Programmieren war, sondern das Verstehen des Problems. Bei einem Nachbau ist dieses Verstehen bereits erledigt, und zwar von jemand anderem. „Software is over“ verallgemeinert also ausgerechnet von dem einen Fall, in dem der schwierigste Teil der Arbeit längst getan war, auf all die anderen, in denen er noch bevorsteht. KI hat das Kopieren billig gemacht, nicht das Erfinden.



Source link

Verwandte Themen:
Weiterlesen

Entwicklung & Code

Inference Manager: neues Ubuntu-Tool verwaltet lokale KI-Modelle


Mit dem Inference Manager hat Canonical auf der hauseigenen Tagung „Ubuntu Summit“ ein neues Werkzeug vorgestellt, um lokal installierte KI-Modelle zu verwalten. Das Tool stellt den Kommandozeilenbefehl inference bereit, der Modelle auf dem eigenen Computer installiert und verfügbar macht. Über eine HTTP-Schnittstelle können dann Programme auf die KI-Inferenz zugreifen. Laut Canonical ist sie zur OpenAI-API kompatibel, sodass sich bestehende Clients direkt anbinden lassen.

Weiterlesen nach der Anzeige

Mit der aktuellen Ubuntu-Version, 26.10 Stonking Stingray, wurde ein KI-Feature veröffentlicht: Myna ist ein Speech-to-Text-Programm, das auf Desktopsystemen flüssiges Diktieren ermöglicht und das Ergebnis in beliebige Textfelder schreibt. Es setzt auf sogenannte Inference-Snaps auf: Snap ist Ubuntus hauseigenes Paketformat, und im Snap Store sind verschiedene KI-Modelle verfügbar, die komplett auf dem eigenen Gerät laufen und keine Internetverbindung benötigen. Als einheitliche Schnittstelle steht nun der Inference Manager bereit, mit dem Modelle verwaltet werden können. Über TCP-Port 8400 lassen sich alle installierten Modelle ansprechen: Chat-Assistenten auf dem Desktop, Coding-Agenten im Editor oder eben Speech-to-Text-Programme können so auf ihre entsprechenden Modelle zugreifen.


Eine Carrera-Rennbahn mit zwei fahrenden Autos auf einem Fußboden, die mit Ubuntu-Logos dekoriert ist.

Eine Carrera-Rennbahn mit zwei fahrenden Autos auf einem Fußboden, die mit Ubuntu-Logos dekoriert ist.

Die Autos werden von einem KI-Modell gesteuert, das Befehle entgegennimmt.

(Bild: Marvin Shah / heise medien)

Auf dem Ubuntu Summit machte Canonical dieses Konzept mit einer Carrera-Bahn erlebbar, bei der KI-Modelle die Autos steuerten. In einer Webapplikation ließen sich verschiedene Modelle auswählen, die „Fahrer“ reagierten auf Sprachbefehle wie „fahr schneller“.


Ein Monitor zeigt ein Rennspiel-Dashboard mit Grafiken und Live-Daten.

Ein Monitor zeigt ein Rennspiel-Dashboard mit Grafiken und Live-Daten.

Der „Ubuntu Summit GP“ soll die Möglichkeiten des Inference Managers demonstrieren.

(Bild: Marvin Shah / heise medien)

Der Inference Manager wird als Snap ausgeliefert und kann mit sudo snap install inference oder über das App Center installiert werden. Danach können mit Befehlen wie inference install smollm2 Modelle installiert werden, um sie anschließend zu nutzen. Inference Manager ist ab sofort im Snap Store verfügbar.


Ein Terminalfenster zeigt Befehle wie inference models und status mit Ausgaben.

Ein Terminalfenster zeigt Befehle wie inference models und status mit Ausgaben.

Inference Manager verwaltet lokale KI-Modelle.

(Bild: Marvin Shah / heise medien)

Während Teile der Open-Source-Community den Einsatz von KI kontrovers diskutieren, will Canonical bei Ubuntu auf lokal laufende Open-Weight-Modelle setzen. Geplant sind etwa kontextsensitive Hilfe bei der Fehlersuche, bessere Spracherkennung für die Barrierefreiheit und Automatisierungen durch agentische Workflows. Die KI-Funktionen sollen laut Canonical als Opt-in kommen und sich jederzeit deinstallieren lassen.


(ktn)



Source link

Weiterlesen

Entwicklung & Code

AWS Emulator im Detail: Die ganze Cloud auf dem eigenen Rechner?


close notice

This article is also available in
English.

It was translated with technical assistance and editorially reviewed before publication.

.

Amazon Web Services (AWS) hat einen eigenen AWS Emulator veröffentlicht. Er bildet die AWS-APIs auf dem eigenen Rechner nach, AWS CLI, SDKs und Coding-Agenten schicken ihre Aufrufe an einen lokalen HTTPS-Endpunkt. Mit seinem Stolz darauf, dass der Emulator vollständig von KI-Agenten entwickelt wurde, setzte sich AWS aber direkt in die Nesseln: Die Rezeption fiel kritisch aus – wie bei hundertprozentig KI-generierter Software zurzeit üblich – und dem Vergleich mit etablierten Drittanbieter-Tools wie LocalStack hält der Emulator wohl noch nicht stand.

Weiterlesen nach der Anzeige

Entwickler könnte er dennoch interessieren: AWS-Anwendungen lassen sich ohne Deployment lokal testen, CI/CD-Pipelines brauchen keine AWS-Zugangsdaten mehr und – was AWS besonders unterstreicht – Coding-Agenten können schneller und risikoärmer Ressourcen anlegen und Ergebnisse prüfen. AWS bringt also agentisch entwickelte Software für die Entwicklung mit Agenten. Es fällt keine Servicegebühr an, ein AWS-Konto braucht es nicht und der Quellcode steht unter der CC0-Lizenz auf GitHub.

iX-plore ist die Online-Serie des iX-Magazins für alle, die neue Tools und Technologien entdecken möchten. In kurzen Beiträgen stellen wir vor, was sie können, wofür sie sich eignen und warum sich ein genauerer Blick lohnen könnte.

Realismus dank Fidelity-Tests

Der Emulator ist in Rust geschrieben, die Dienste erzeugt AWS aus denselben API-Modellen, aus denen auch die SDKs entstehen. Kommt ein Dienst oder eine API hinzu, tauchen sie im Emulator auf. Alle Dienste, für die ein Modell im öffentlichen Repository AWS API Models liegt, werden auch unterstützt.

Wie genau der Emulator AWS nachbildet, misst AWS mit Fidelity-Tests. Jeder Test ist ein kurzes Python-Programm, das über das AWS-SDK boto3 einen Ablauf durchspielt, etwa ein Objekt zu speichern, zu lesen und wieder zu löschen. Die Abläufe werden dann gegen die echte Cloud geprüft, als Referenz dient die Region US West (Oregon), während globale Dienste in US East (N. Virginia) geprüft werden. Der Emulator besteht einen Test nur, wenn bei jedem Aufruf Statuscode, Antwort, Fehlercode und Fehlermeldung mit der Cloud übereinstimmen, dasselbe gilt für die Ressourcen und Daten, die der Ablauf erzeugt. Die Testsuite umfasst Zehntausende Tests, ist öffentlich und enthält auch die, die noch scheitern. Mit dem Python-Programm fidelity_tests_runner können Nutzer die Tests lokal gegen den Emulator laufen lassen.

Trotz der hohen API-Abdeckung hat die Emulation aber bewusste Grenzen: Für Sicherheitstests eignet sich das Tool laut AWS nicht, da es weder IAM- noch ressourcenbasierte Richtlinien wie die echte Cloud auswertet. Auch Cross-Account- und Cross-Region-Szenarien bildet es nicht ab, sämtliche Aufrufe laufen unter einer festen Dummy-Konto-ID.

Jede Instanz des Emulators bekommt einen eigenen Port, eigene Schlüssel und einen eigenen Zustand im Arbeitsspeicher. Mehrere Agenten oder CI-Jobs teilen sich also keine Buckets, Tabellen oder Queues und arbeiten parallel, ohne sich gegenseitig Ressourcen zu überschreiben. Nutzer des AWS SDK for Rust können den Emulator außerdem im Embedded-Modus betreiben, wobei er direkt ins Test-Binary kompiliert wird. Er läuft dann im selben Prozess und der Test übergibt dem SDK einen HTTP-Client des Emulators statt des Netzwerk-Connectors. Auch hier sind die Instanzen voneinander isoliert, sodass Tests parallel laufen können.

Weiterlesen nach der Anzeige

Installation und Betrieb

Coding-Agenten können den Emulator mit dem Skill aws-emulator direkt installieren, starten und verbinden, dafür braucht es allerdings die AWS CLI ab Version 2.35.0. Solche Skills sind im Prinzip Markdown-Anleitungen, die der Agent bei Bedarf lädt. Der Befehl aws agent-toolkit add-skill in der AWS CLI installiert sie für alle Agenten, die es auf dem Rechner findet. Unter Linux gibt es RPM- und Debian-Pakete, unter Windows und macOS einen Docker-Container. Ein fertiges Docker-Image gibt es nicht, das müssen Nutzer aus einem kurzen Dockerfile aus der Dokumentation zusammenbauen. Standardmäßig sendet der Emulator anonymisierte Nutzungsdaten an AWS, was sich jedoch per Start-Flag oder Umgebungsvariable abschalten lässt.

Wer den Emulator selbst kompiliert, braucht Linux auf x86_64 oder aarch64, eine Rust-Toolchain, einen C-Compiler und mindestens 100 GByte freien Speicherplatz für die Build-Artefakte. Jeder emulierte Dienst ist ein eigenes Rust-Paket (Crate), weshalb schon ein Debug-Build sehr groß wird. Das gilt auch für den Embedded-Modus, denn der erste cargo test-Lauf kompiliert sämtliche Service-Crates des Emulators mit. AWS empfiehlt, das Build-Verzeichnis in der CI zu cachen und den Emulator auf einen Release-Commit festzulegen.

„Vibecode“ von AWS?

Matthew Goldberg, Senior Principal Engineer im Developer-Tools-Team von AWS, setzt mit dem Emulator eine KI-Duftnote: Nicht nur ist die Software vor allem auf das schnelle Testen von agentischer KI zugeschnitten, sondern sie ist laut Amazons Firmenblog auch ausschließlich von autonomen Agenten geschrieben. Das Team hat den Code weder verfasst noch geprüft. Goldberg beschreibt, wie ihn der autonome Bau eines C-Compilers von Agenten dazu inspirierte und der Emulator aus einem simplen Wochenendprojekt hervorging. Ein Team von Agenten pflegt die Testsuite, ein zweites sucht Abweichungen von der echten Cloud, ein drittes setzt die Korrekturen um. Jede Änderung muss zudem vor dem Merge ein automatisiertes Quality Gate passieren, an dem weitere Agenten unter anderem die Sicherheit des Codes kontrollieren.

Die autonome Entwicklung lässt sich in den Repository-Verzeichnissen issues/things-that-now-work und issues/things-that-do-not-work nachvollziehen, in die die Agenten hineinschreiben. Menschliche Hilfe von außen ist dabei nicht vorgesehen: Zwar können Nutzer auf GitHub Fehler melden, Pull-Requests nimmt AWS für das Projekt aber nicht an. Ganz unabhängig von dem Tool an sich ist hier also anschaulich zu sehen, in welche Richtung Softwareentwicklung gerade steuert – und wie die großen Systemhäuser versuchen, Vibe-Coding sinnvoll anzugehen.


(kki)



Source link

Weiterlesen

Entwicklung & Code

Gestohlene Token: Secret-Stealer in Tausenden GitHub-Repositories


Mit gestohlenen Zugriffstoken für GitHub-Konten schleusen unbekannte Angreifer seit Dienstag Schadcode in Repositories ein, der die Secrets aus GitHub Actions und Cloudzugangsdaten abgreift.

Weiterlesen nach der Anzeige

Das Sicherheitsunternehmen Aikido zählt im Rahmen der auf den Namen wfx-loot getauften Kampagne bereits 4837 übernommene Konten, über die die Angreifer 61.764 Repositories attackiert haben. In mehr als 1800 Fällen sollen Workflows den Schadcode bereits ausgeführt haben.

Die Angreifer nutzen anscheinend keine Lücke in GitHub Actions aus, sondern missbrauchen die Schreibrechte gestohlener Token. Woher diese stammen, ist nur teilweise geklärt. Laut Fly.io wurden Token seiner GitHub-App missbraucht, die aus öffentlich erreichbaren .git/config-Dateien stammten; der Hoster widerruft sie. Eine Stellungnahme von GitHub liegt noch nicht vor.

Das Sicherheitsunternehmen SafeDep hat Schadcode-Commits bereits in über 8000 öffentlichen Repositories gefunden. Noch am Donnerstagmittag listete die GitHub-Suche mehr als 66.000 der typischen Test-Pull-Requests, rund 4300 davon vom selben Tag.

Ähnlich wie zuletzt beim Wurm testmetest erreichen Angreifer laut Aikido über Mitwirkenden- und Organisationsrechte mit über 10.000 Test-Pull-Requests auch Repositories, die den übernommenen Konten nicht selbst gehören. Damit können auch Organisationen betroffen sein, deren eigene Zugangsdaten gar nicht gestohlen wurden. Dürfen die Workflows eines Repositorys auf AWS oder Azure zugreifen, nutzt der Schadcode die erbeuteten Zugänge, um Hintertüren in den Cloudkonten einzurichten.

Spuren oft binnen einer Minute verwischt

Die Angreifer lassen ihren Opfern kaum Zeit zu reagieren. Sie öffnen zunächst einen Pull Request, um die Schreibrechte zu bestätigen. Dann folgt der eigentliche Schadcode: ein Shellskript, das die Angreifer in einen bestehenden Workflow einfügen, als neuen Workflow ablegen oder in npm-Projekten bei jeder Installation starten lassen.

Meist schon innerhalb einer Minute machen die Angreifer die Änderungen rückgängig und löschen den Workflow-Lauf samt Logs. Oft weist nur eine fehlende Laufnummer auf den Angriff hin. Eine Branch-Protection für vorgeschriebene Status-Checks kann das Skript mit gefälschten Erfolgsmeldungen aushebeln. Aikido zufolge setzt das Skript solche gefälschten Status-Checks tatsächlich ab; in den von SafeDep untersuchten Proben war diese Funktion dagegen nicht aktiviert.


Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

Mit einem gestohlenen Token testen die Angreifer zuerst ihre Schreibrechte, bevor sie den Stealer auf einem von drei Wegen einschleusen und die Änderung wieder zurücknehmen.

(Bild: SafeDep)

Neben Token für KI-Dienste wie OpenAI, Anthropic oder Cursor fischt das eingeschleuste Skript insbesondere die Secrets aus GitHub Actions ab, außerdem Zugangsdaten für Clouddienste, Container-Umgebungen, Paketregister und SSH.

Weiterlesen nach der Anzeige

Haben die Bedrohungsakteure erst einmal Zugang zu Sitzungen bei AWS, Google Cloud und Azure, geht der Angriff weiter: Bei AWS öffnet das Skript eine IAM-Rolle für jedes AWS-Konto, in Azure trägt es zusätzliche Anmeldewege für Workflows aus dem kompromittierten Repository ein. Erbeutete Daten schickte das Skript laut Aikido in dieser Kampagne per HTTP an Server der Angreifer. SafeDep fand in untersuchten Payloads zudem eine Exfiltration über Telegram.

Selbsttest: Ein Pull Request verrät das gekaperte Konto

Entwicklerinnen und Entwickler, die seit Dienstag einen Branch wfx-docs, den Pull-Request docs: dependency audit notes oder Commits wie ci: refresh build cache, chore: add ci helper und chore: add dependency audit workflow in ihren Repositories finden, sollten das zugehörige Konto als kompromittiert ansehen, auch wenn noch kein Schadcode folgte. Verdächtig sind laut den Sicherheitsforschern von Aikido zudem kurzlebige Branches, die mit chore/ beginnen und auf acht Zufallszeichen enden. Betroffene sollten Token, OAuth-Freigaben und SSH-Schlüssel ihres Kontos widerrufen.

Wurde bereits Schadcode ausgeführt, müssen Betroffene neben dem Austausch der Secrets auch die Hintertüren eigens entfernen, etwa AWS-Rollen, die jedem Konto vertrauen, oder in Azure Federated Credentials mit dem Präfix wfx-ci-. Wer npm install auf einem betroffenen Commit ausgeführt hat, muss auch den eigenen Rechner als kompromittiert betrachten.

Der Schadcode gelangte auch in Paketdistributionen. Aikido nennt das Packagist-Paket digitalelvis/neuronai-studio 3.14.3 sowie die Go-Modul-Versionen github.com/onuragtas/docker-env v1.0.278 und v1.0.280. SafeDep führt darüber hinaus github.com/onuragtas/redock, eine weitere docker-env-Version und eine über den Go-Modul-Proxy verfügbare Pseudo-Version von github.com/vkuznet/gocurl auf. Bei den Go-Modulen liegt der Schadcode in einer GitHub-Actions-Workflow-Datei; ein gewöhnlicher Go-Build führt diese nicht aus. Wer ein solches Modul lediglich als Go-Abhängigkeit einbindet, ist dadurch wahrscheinlich nicht betroffen.


(mro)



Source link

Weiterlesen

Beliebt