Gitea: Gitebot-Konto wurde kompromittiert

Seien Sie in der Zwischenzeit bitte vorsichtig, wenn Sie unsere freigegebenen Binärdateien, insbesondere die von Windows, bis auf weiteres herunterladen. Achten Sie zB auf die Größe der Binärdateien oder eine doppelte .exe Dateiendung.
Wir haben herausgefunden, dass unsere .exe-Binärdateien in Version 1.4.2 ebenfalls geändert wurden.

Wir arbeiten hart daran, allen Spuren zu folgen, aufzuräumen und so schnell wie möglich wieder ins Tagesgeschäft zurückzukehren.

@daviian Vielleicht ist es dann notwendig, Releases zu unterschreiben?

@Mauladen Danke für deinen Beitrag. Wir werden das auf jeden Fall besprechen.

Autsch! Ja, signierte Binärdateien wären ideal.

@Mauladen Wir haben die Binärdateien für die Version 1.4.2 neu erstellt, um sicherzustellen, dass wir sichere bieten.

Oder meintest du was anderes?

Das ist normal. Wir haben 1.4.2 neu getaggt, um CI erneut auszulösen, um Binärdateien neu zu erstellen, da Windows-Binärdateien für diese Version entfernt wurden und eine neue bösartige hinzugefügt wurde

@daviian , Vielleicht hat @Mauladen gemeint, dass 1.4.2 Release Commit ohne GPG-Signatur ist, aber 1.4.1 war

Die Liste der Änderungen muss noch bearbeitet werden

@axifive- Commit, wo nicht gpg vom Benutzer signiert wurde, sondern github, das dies automatisch (mit github-Schlüssel) tut, wenn die Fusion mit dem PR-Autor identisch ist. Ich würde es nicht für sicherer halten, denn wenn der Github-Account kompromittiert würde, werde ich auch als "verifiziert" angezeigt. Aber wir könnten ab jetzt anfangen zu signieren (zu diskutieren). Zur Information, wir arbeiten daran, Binärdateien zu signieren, da es einfacher ist, die Binärdatei als den Git-Commit-Baum zu korrumpieren.

Sie sollten einen Tarball hochladen, der von git-archive (zusätzlich zu denen, die github automatisch generiert), die Sie mit signify signieren. Wie das funktioniert/aussieht, können Sie sich hier vorstellen:

• https://github.com/nicklan/pnmixer/blob/master/MAINTAINING.md#releasing
• https://github.com/nicklan/pnmixer/releases/tag/v0.7.2

Libressl verwendet die gleiche Technologie.

Gibt es dazu noch Infos? Was war die Nutzlast der Binärdatei? Werden die Benutzer darüber durch einen Blogbeitrag oder ähnliches informiert? Wurden irgendwelche der Linux-Binärdateien kompromittiert? Ich bin ziemlich besorgt darüber, was diese Dinge mit meinen Servern gemacht haben könnten. Ich bin doppelt besorgt, dass ich nur zufällig auf der Problemseite im Vergleich zu einem offiziellen Hinweis auf der Projektseite / im Blog davon erfahren habe

Kann die Version von Gitea 1.4.2 zu diesem Zeitpunkt sicher aus dem Quellcode aktualisiert werden?

An dieser Stelle ist mir nicht klar, ob nur Binärdateien betroffen waren. Wie haben Sie dies verifiziert? Sind Ihre Filialen geschützt?

Shasums unterscheiden sich bei Binärdateien, die ich am 6/4 und 6/7 heruntergeladen habe, obwohl sie die gleiche Anzahl von Bytes haben:

$ sha256sum gitea-1.4.2-linux-amd64*
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d  gitea-1.4.2-linux-amd64.1

$ ls --color=tty -l gitea-1.4.2-linux-amd64*
-rwxr-xr-x 1 matt matt 53674800 Jun  4 20:39 gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 matt matt 53674800 Jun  7 08:18 gitea-1.4.2-linux-amd64.1

Haben Sie Lust, diese irgendwo zu hosten, damit die Leute sie auseinanderreißen können?

Habe die Binärdateien hier hochgeladen: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Ich werde sie bei Bedarf an einen dauerhafteren Ort stellen.

Frage: Sind nur die Binärdateien auf der Website betroffen oder waren auch die Repositorys betroffen? Ich frage, weil ich gestern von Gitea gehört habe und den Zweig v1.4 geklont und gebaut habe.

Ich hätte gerne mehr Informationen, wenn die Quelle selbst kompromittiert ist oder nur die Binärdateien. Ich führe ein Skript aus, um nachts nach Updates/Builds von git zu suchen, und hatte das Glück, dies aufgrund des Timings zu verpassen.

Ist die aktuelle Version 1.4.2 als sauber verifiziert? Wenn wir wissen, dass das verdorben ist, sollten wir das so schnell wie möglich ziehen und woanders zur Analyse ablegen, sonst werden die Leute es immer noch herunterladen, wenn sie dieses Problem nicht sehen. Ich stimme @CountMurphy zu , können wir der README etwas hinzufügen, damit es wirklich sichtbar ist?

Können wir Hashes erhalten, damit wir überprüfen können, ob unsere Binärdateien betroffen sind? Meine gitea 1.4.1 (linux amd64) sieht so aus:
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Ich habe gerade gitea 1.4.1 linux-amd-64 heruntergeladen und habe d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 auch als sha256 erhalten

@mikedilger Siehe: https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229

Um es ganz klar zu sagen: Niemand weiß etwas und die einzigen sicheren Hashes sind die, die derzeit hier zu finden sind: https://github.com/go-gitea/gitea/releases

Für Gitea 1.4.2 auf AMD64 bedeutet das:

Tut mir leid, ich habe https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 falsch verstanden, um zu bedeuten, dass beide Binärdateien kompromittiert wurden.

Ich habe diesen Beitrag bearbeitet, um Unklarheiten darüber zu beseitigen, was wir tatsächlich wissen.

Moment mal: laut diesem Kommentar (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229) gibt es zwei shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 vom 4.06.

Sagen wir, dass beide kompromittiert sind oder nur einer von ihnen? Für die Aufzeichnung ist die auf meinem Server e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 vom 5. Juni.

@christianbundy , Bitte Teammitglieds

Bitte ziehe keine voreiligen Schlüsse, warte auf eine Antwort des Teammitglieds

Tut mir leid, ich dachte, die Datei-Hashes würden sofort von einem Teammitglied gepostet und wusste nicht, dass die Informationen von jemand anderem kamen, der _auch_ im Dunkeln tappte. Ist dies der richtige Kanal, um die neuesten Entwicklungen zu verfolgen? Ich habe meinen Server ausgeschaltet und benötige weitere Informationen, um festzustellen, ob ich infiziert wurde.

Ich sehe, dass Ihre Änderungen den Eintrag, auf den ich hingewiesen habe, durchstreichen. ABER, ist das nicht zu früh, um daraus Schlüsse zu ziehen? Woher wissen wir sicher, dass e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 in Ordnung ist?

Uns fehlen noch ein paar Informationen (wahrscheinlich nicht erschöpfend):

• [ ] Welche Binärdateien wurden kompromittiert und wie hoch sind ihre Prüfsummen?
• [ ] Wann wurde das Bot-Konto kompromittiert?
• [ ] Ist das Quell-Repository kompromittiert (dies kann leicht zu überprüfen sein, wenn Sie eine Version des Repositorys von vor einiger Zeit geklont haben, dann können Sie möglicherweise Diffs oder Beweise für Force-Pushs überprüfen).

Ich habe:

# ls -la gitea-1.4.1-linux-amd64
-rwxr-xr-x 1 gitea gitea 53663640 May  3 08:02 gitea-1.4.1-linux-amd64

Mit sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

und ich habe gerade gitea-1.4.2-linux-amd64 heruntergeladen:

# ls -la gitea-1.4.2-linux-amd64
-rwxr-xr-x 1 root root 53674800 Jun  7 14:18 gitea-1.4.2-linux-amd64

Mit sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d das der bereitgestellten .sha256-Datei entspricht: gitea-1.4.2-linux-amd64: OK die sicher sein sollte. (rechts?)

[...] Wir haben die Binärdateien für die Version 1.4.2 neu erstellt, um sicherzugehen, dass wir sichere sind. […]

Ich habe gitea-1.4.2-linux-amd64 zur Analyse hier hochgeladen, aber es sagt nichts Offensichtliches aus.

Ich werde mir dieses Problem ansehen und meine gitea-Installation vorerst offline halten.

Woher wissen wir sicher, dass e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 in Ordnung ist?

@shuhaowu Ich sagte, dass c843d462 in Ordnung sei, nicht e14e54f3 . Wir wissen dies, weil dies die Datei ist, die derzeit auf GitHub bereitgestellt wird und die sie kürzlich neu erstellt haben.

Wenn 1.4.2 neu erstellt wurde, sollte diese wie die anderen gültigen Versionen signiert und verifiziert werden. Dies nicht zu tun, erhöht nur die Verwirrung.

@xcolor

Habe die Binärdateien hier hochgeladen: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

Der einzige Unterschied zwischen diesen beiden Binärdateien besteht darin, dass etwa 2000 Instanzen von movabsq $63663754793, %rcx durch movabsq $63663969431, %rcx . Ich kann nicht genau sagen, was das Verhalten ändert, aber ich halte es für sehr unwahrscheinlich, dass es ausreicht, um bösartig zu sein.

Vielleicht eine neue (signierte?) Version 1.4.3 mit dem bekannten sicheren Code herausbringen, oder würde das die Dinge noch mehr verwirren?

@justinclift Die Idee

@spaghetti2514

Einerseits haben Sie Recht – die Unterschiede zwischen den _diesen_ zwei Binärdateien sind leicht zu erkennen.

Auf der anderen Seite hat das Gitea-Team nicht wirklich gepostet, welche Binärdateien betroffen waren, keine SHA256-Hashes gepostet oder wirklich _alles_ gesagt, das uns helfen würde, den Kompromiss zu verstehen Wie andere darauf hingewiesen haben, haben wir nicht annähernd genug Informationen, um festzustellen was ist passiert und wer ist betroffen.

Es macht mich frustriert, darauf hinzuweisen, dass wir wahrscheinlich das Schlimmste annehmen und auf diagnostische Schritte vom Kernteam warten sollten. Vor diesem Hintergrund weiß ich es zu schätzen, dass Sie das zerlegte Diff gepostet haben.

Ist das das, was Sie suchen? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

Danke für das Update @lafriks !

Ich habe die Problembeschreibung mit zusätzlichen Informationen aktualisiert. Es war nicht so schlimm, wie es hätte sein können. Wir wollten so transparent wie möglich sein und haben dieses Problem erstellt, sobald wir alles aufgeräumt und behoben haben und da dies zum ersten Mal passiert ist, also hätten wir wahrscheinlich schneller mehr Informationen geben sollen, Entschuldigung für die Verwirrung.

@lafriks Danke für das Update! Könnten Sie Ihren PGP-Schlüssel posten, den wir in Zukunft verwenden können, um Commits zu überprüfen?

@4oo4- Tags werden von einem der

Veröffentlichungen werden mit einem GPG-Schlüssel signiert, der vor der Veröffentlichung von 1.5.0 erstellt wird. Wir werden ihn auf README.md, gitea docs und in einem Blogbeitrag veröffentlichen.

Als Benutzer von 386 kann ich bestätigen, dass die Binärdatei gitea-1.4.1-linux-386 derzeit auf der Seite Releases verfügbar ist, mit einer Version übereinstimmt, die ich am 4. Juni heruntergeladen habe ( cf6344b4 ).

Da alle PRs mit Squash&Merge zusammengeführt wurden, sind sie nicht signiert (oder vielleicht von GitHubs Magie signiert :) )

Verwenden Sie nicht den Merge-Button, das ist im Grunde unsicher und ein zufälliger gpg-Schlüssel. Lokal zusammenführen und die Zusammenführung pushen.

@mappu gitea v1.4.1 war nicht betroffen und jetzt wurde v1.4.2 erneut veröffentlicht.

Sie sollten einen von git-archive erstellten Tarball hochladen (zusätzlich zu denen, die github automatisch generiert), die Sie mit signify signieren.

Eigentlich müssen Sie nicht einmal die Archive erstellen und erneut hochladen. Sie können das von GitHub erstellte signieren, da dies reproduzierbar ist.

Hier ist ein kleines Skript dafür: https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Nützlich aussehendes Skript. :Lächeln:

Hat ein beitragendes Teammitglied ein Archiv von 1.4.2 vor der Entdeckung der Sicherheitsverletzung erhalten?

Sie scheinen viele Leute im Unklaren gelassen zu haben, ob diese Binärdatei für irgendwelche Linux-Versionen geändert wurde oder nicht, was eine ziemlich wichtige Information ist, wenn man bedenkt:

1) Die meisten Bereitstellungen erfolgen auf Linux-Stacks

2) Linux-Stacks sind nicht an binäre Trojaner gewöhnt und eignen sich normalerweise nicht für die besten Tools zum programmgesteuerten Erkennen von verdächtigem Code, der bereits auf dem System ausgeführt wird.

Obwohl ich gerne glauben würde, dass dies ein einfacher auf Windows ausgerichteter Angriff war und nichts weiter, scheint die Tatsache, dass dieses spezielle Repository nur wenige Tage nach einem dramatischen Anstieg des Benutzerbasiswachstums ins Visier genommen wurde, auf einen besser orchestrierten Versuch hinzuweisen. Ich bezweifle stark, dass jeder, der wusste, worauf er abzielte und wie man so etwas durchziehen kann, eine so reife Gelegenheit verpasst hätte, so viele Hosts wie möglich zu infizieren.

@stanier dl.gitea.io war nicht betroffen und wir haben überprüft, dass keine anderen Binärdateien manipuliert wurden

Das erklärt, warum sich unser Webproxy weigerte, das neueste gitea-Image von hub.docker.com herunterzuladen ...

@lafriks Können Sie also bestätigen, dass c843d462 und e14e54f3 beide sicher sind? Wenn das CI einen Build mit einer anderen Signatur bereitgestellt hat, muss sich entweder am Quellcode oder an den Parametern, die der Compiler für den Build verwendet hat, etwas geändert haben. Es ist an sich eine kleine Formsache, aber es wurde hier nie direkt gesagt, ob der Gegner die 1.4.2-Linux-Binärdateien geändert hat oder nicht, nur die entsprechenden .exe-Binärdateien, die im Kommentar von @daviian erwähnt werden.

Nur um das klarzustellen, ich frage nach den Binärdateien der Veröffentlichungsseite des GH-Repos, nicht nach dl.gitea.io. Ich verstehe, dass außerhalb des GH-Repos nichts manipuliert wurde.

Linux-Stacks sind nicht an binäre Trojaner gewöhnt und eignen sich normalerweise nicht für die besten Tools zum programmgesteuerten Erkennen von verdächtigem Code, der bereits auf dem System ausgeführt wird.

Hmmm, bieten die meisten Paketmanager (und ähnliches) nicht die Möglichkeit, mindestens sha*-Prüfsummen zu überprüfen? Nicht unbedingt nur zum Erkennen von Malware, sondern als "lassen Sie uns überprüfen, ob der Download nicht beschädigt ist".

@justinclift ja, aber das gilt nur für Binärdateien, die über den Paketmanager installiert wurden. Das fragliche Problem betrifft hier einen direkten Download von GitHub, der meines Wissens keine eingebettete Malware-Erkennung hat.

Ähhh. Der Begriff "Linux-Stacks" hat mich abgeschreckt, da ich es eher gewohnt bin, dass direkte Downloads einfache Einzelfälle sind (zB beim Prototyping), als etwas, was eine automatisierte Lösung tun würde. Kein Problem. :Lächeln:

@stanier der Build wurde per Drohne erneuert, um alles zu löschen. Go stellt nicht jedes Mal dieselbe Binärdatei bereit, wenn Sie die Binärdatei erstellen, da sich einige Variablen ändern können (z. B. die Buildzeit), sodass es normal ist, dass sich der Hash unterscheidet.
Ich habe während der Untersuchung alle Binärdateien erhalten und kann Hashs bereitstellen, sobald ich auf meinem PC ankomme.

Für alle, hört bitte auf, über Gerüchte zu diskutieren und konstruktive Beiträge zu leisten.
Ich verstehe, dass Sie sich um Ihre Sicherheit sorgen und uns sehr wichtig ist (da wir auch als Nutzer von gitea an Ihrer Stelle sind). Aktuell wurde der Zugang geändert und wir haben keine verdächtigen Aktivitäten mehr gesehen. Wir haben dieses Problem gemacht, um so schnell wie möglich zu informieren, um transparent zu sein und in der Lage zu sein, Eingaben von Daten zu erhalten, die für die Untersuchung nützlich sind oder einen Punkt verpasst haben, da niemand perfekt ist.
Wir werden eine Obduktion durchführen, um zu erklären, was passiert ist, und wir haben definitiv über Maßnahmen nachgedacht, um dies in Zukunft zu verhindern.
Wenn dieses Thema wild wird, müssen wir meines Erachtens schließen, um nur nützliche und prägnante Informationen zu behalten und die Debatte dahin zu bringen, wo sie hingehört.

Um eine solche Situation in Zukunft zu vermeiden, werden wir mit der nächsten Version alle Binärdateien signieren. Ich habe ein Plugin für Drone erstellt, das Sie unter https://github.com/drone-plugins/drone-gpgsign finden (die Dokumentation für dieses Plugin muss erstellt werden), das alle Binärdateien signiert, der öffentliche Schlüssel wird hochgeladen zum Download-Server und zu einem Schlüsselserver, dann können Sie die Binärdateien immer vertrauenswürdig überprüfen.

Nur um Ihnen ein Beispiel zu zeigen, wie das aussehen wird und was die Ergebnisse sind, können Sie einen Blick auf https://github.dronehippie.de/webhippie/ldap-proxy/49/18 und https://dl.webhippie.de werfen

Wenn Sie der Meinung sind, dass diesem Plugin etwas wirklich Wichtiges fehlt, können Sie gerne ein Problem im Plugin-Repository öffnen und ich kann es ansprechen.

@sapk Danke für die Klarstellung. Ich entschuldige mich, es ist mir völlig entgangen, dass das Projekt auf Golang basiert – die meisten Probleme wie dieser beschäftigen sich mit älterer Software, also denke ich, dass mein Verstand auf eine falsche Beziehung gesprungen ist. Mein Fehler.

Ich habe angefangen, mir die hochgeladene Binärdatei install.exe anzusehen: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Es scheint, dass nicht nur Gitea davon betroffen war, sondern auch https://github.com/opencompany/www.opencompany.org/releases

Vielen Dank für die klare Erklärung.

Ich denke, dieses Problem ist der Hauptgrund, eine vertriebsspezifische Verpackung zu verwenden. Es lenkt mehr Aufmerksamkeit auf die Verpackung und potenziell bösartigen Code/Binär (insbesondere im Falle eines so groben Versuchs). Es wäre toll, zumindest Debian/RedHat/Archlinux-Pakete für Gitea zu haben: Das würde viele Leute daran hindern, eine beliebige Binärdatei auf ihrem Produktionsserver auszuführen :)

Reicht die PGP-Signierung der Veröffentlichungen aus? Wahrscheinlich. Stellen Sie nur sicher, dass Sie Ihren öffentlichen Schlüssel auf vielen verschiedenen Plattformen bewerben, damit die Kompromittierung Ihrer Website nicht dazu führt, dass jeder falsche Schlüssel herunterlädt. (Aber ein Debian-Paket in den Backports wäre <3)

(Auch reproduzierbare Builds ?)

Da Sie mit dem Signieren von Binärversionen beginnen werden, könnten Sie auch erwägen, die Docker-Images zu signieren, die an die Registrierung gepusht werden?

Es scheint, dass nicht nur Gitea davon betroffen war, sondern auch https://github.com/opencompany/www.opencompany.org/releases

Habe gerade direkt eine E-Mail an ihre Kontaktpersonen gesendet, falls sie sich noch nicht mit ihren GitHub-Problemen befasst haben.

@graystevens Sollten die Pastebin-Mitarbeiter kontaktiert werden, um diese Pastebin-Adresse zu

Vielen Dank an alle. Würde meinen Server erneut herunterladen und wieder hochfahren

@justinclift Ich werde das Einfügen jetzt an PasteBin melden - ich habe eine Kopie des Inhalts, damit wir die Ausgabe für die Malware bei Bedarf neu erstellen können. Guter Ruf

Um fair zu sein, hat Go jetzt einen reproduzierbaren Build: https://blog.filippo.io/reproduction-go-binaries-byte-by-byte/
Das ist vielleicht cgo für sqlite und einige Build-Umgebungen, die sie nicht reproduzierbar machen.

Nur zur Information, die vorherige neu erstellte und unberührte Hash- Liste. Wenn Sie diesen Hash haben, bedeutet dies, dass Sie die Binärdatei vor dem Rebuild haben, den wir zum Zurücksetzen der Version 1.4.2 und auch vor dem Angriff durchgeführt haben. Wenn dies der Fall ist, können Sie bei ihnen bleiben.

156655506d373241fea6b8955acbe6fdc148f06b49b4f6e46d11cadcd00d7316  gitea-1.4.2-darwin-10.6-386
5730c1a471dfc2c055442360d431c950b3a4f266403c5f327c94a68b88e67a10  gitea-1.4.2-darwin-10.6-amd64
8c3cc2127161695dea512176cd4282711e8c57972f333253cc89597dfab002ef  gitea-1.4.2-linux-386
e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9  gitea-1.4.2-linux-amd64
bca75d81c52b9aa57fd05b8f7ce0572abae3e1a008d8ab77840ca08c53975867  gitea-1.4.2-linux-arm-5
3aa791afce2e3450461038e09622fe04f34b891c47db641be50b6cc3f772645e  gitea-1.4.2-linux-arm64
fc73d06621fc23a944a2a8ee3b19fbd8edb972b0cdaefa67248eb885aa4d6240  gitea-1.4.2-linux-arm-6
5b76cd9b84846c09ba3627219a6cad99542a53d8eec71a427a433ab82eaabacf  gitea-1.4.2-linux-arm-7
4fafeabfa069066fd624364b47b5729f8f068545d4cd8a3620774a982937ac16  gitea-1.4.2-linux-mips64le
7d9e0afcd315f0efbfb26cab303b3fee3939fa0e081b0d3f4f480f950d0a9870  gitea-1.4.2-linux-mips64
7f2e3c1163823889bec1fdd34b4135149c83d53b6dc86f186821e51e0f839e53  gitea-1.4.2-linux-mipsle
a1b8338113d4fdb0360582ba18f6fce97722c779493e7d7e07594d78c7c3f003  gitea-1.4.2-linux-mips
82ad50932bd927ead2e7da4e4c575d94f88e0105a82eda4cce1df7c9fc5ba0dc  gitea-1.4.2-windows-4.0-386.exe
86d7332894390ccaedd39be891044d829f54d4cd71fa21fce5dbd9bc3abbce44  gitea-1.4.2-windows-4.0-amd64.exe

Der Cleanup-Pass von install.exe scheint einige Repositorys übersehen zu haben:

• go-gitea/gitea-darkmode
• go-gitea/lgtm-cli
• go-gitea/yaml
• go-gitea/bolt
• go-gitea/lgmt-go
• go-gitea/lgmt-docs

Die meisten davon sind alt und nicht gerade relevant, aber es ist wahrscheinlich keine gute Idee, Malware in der Nähe zu haben.

@lunny

• https://github.com/lunny/html2md/releases
• https://github.com/lunny/tango/releases
• https://github.com/lunny/nodb/releases

• https://github.com/go-xorm/dbweb/releases
• https://github.com/go-xorm/xorm/releases
• https://github.com/go-xorm/builder/releases
• https://github.com/go-xorm/ql/releases
• https://github.com/go-xorm/go-xorm.github.io/releases
• https://github.com/go-xorm/blog/releases
• https://github.com/go-xorm/website/releases
• https://github.com/go-xorm/cachestore/releases
• https://github.com/go-xorm/tidb/releases
• https://github.com/go-xorm/xorm-redis-cache/releases
• https://github.com/go-xorm/manual-zh-CN/releases
• https://github.com/go-xorm/manual-en-US/releases
• https://github.com/go-xorm/cmd/releases
• https://github.com/go-xorm/core/releases
• https://github.com/go-xorm/tests/releases
  

• https://github.com/go-tango/gos/releases
• https://github.com/go-tango/social-auth/releases
• https://github.com/go-tango/wego/releases
• https://github.com/go-tango/manual-en-US/releases
• https://github.com/go-tango/manual-zh-CN/releases
  

• https://github.com/go-xweb/xrun/releases
• https://github.com/go-xweb/log/releases
• https://github.com/go-xweb/docs-zh-CN/releases
• https://github.com/go-xweb/httpsession/releases
• https://github.com/go-xweb/xweb/releases
• https://github.com/go-xweb/uuid/releases
  

• https://github.com/goftp/leveldb-auth/releases
• https://github.com/goftp/xorm-auth/releases
• https://github.com/goftp/xorm-perm/releases
• https://github.com/goftp/posixfs-driver/releases
• https://github.com/goftp/ftp/releases
• https://github.com/goftp/qiniu-driver/releases
• https://github.com/goftp/multiple-driver/releases
• https://github.com/goftp/ftpd/releases
• https://github.com/goftp/file-driver/releases
  

• https://github.com/gobook/gobook/releases
• https://github.com/gobook/bookserver/releases
• https://github.com/gobook/blackfriday/releases
  

• https://github.com/tango-contrib/bind/releases
• https://github.com/tango-contrib/jwt/releases
• https://github.com/tango-contrib/cache-ledis/releases
• https://github.com/tango-contrib/cache-memcache/releases
• https://github.com/tango-contrib/cache-mysql/releases
• https://github.com/tango-contrib/cache-nodb/releases
• https://github.com/tango-contrib/cache-postgres/releases
• https://github.com/tango-contrib/cache-redis/releases
• https://github.com/tango-contrib/counting/releases
• https://github.com/tango-contrib/session-redis/releases
• https://github.com/tango-contrib/session-ssdb/releases
• https://github.com/tango-contrib/session-ledis/releases
• https://github.com/tango-contrib/authz/releases
• https://github.com/tango-contrib/basicauth/releases
• https://github.com/tango-contrib/binding/releases
• https://github.com/tango-contrib/cache/releases
• https://github.com/tango-contrib/captcha/releases
• https://github.com/tango-contrib/debug/releases
• https://github.com/tango-contrib/session/releases
• https://github.com/tango-contrib/xsrf/releases
• https://github.com/tango-contrib/dispatch/releases
• https://github.com/tango-contrib/tpongo2/releases
• https://github.com/tango-contrib/events/releases
• https://github.com/tango-contrib/rbac/releases
• https://github.com/tango-contrib/flash/releases
• https://github.com/tango-contrib/notify-discord/releases
• https://github.com/tango-contrib/renders/releases
• https://github.com/tango-contrib/session-nodb/releases
• https://github.com/tango-contrib/websocket/releases
  

• https://github.com/gobuild/goyaml/releases
• https://github.com/gobuild/got/releases
• https://github.com/gobuild/log/releases
• https://github.com/gobuild/oauth2/releases
• https://github.com/gobuild/gobuild/releases
• https://github.com/gobuild/gopack/releases
• https://github.com/gobuild/travis-autobuild/releases
• https://github.com/gobuild/awesome-go-tools/releases
  

Äh, danke. Was ist der Ansatz, den Sie verwenden, um diese zu finden? Es scheint, dass der von den GitHub-Mitarbeitern verwendete Ansatz nicht wirklich 100% effektiv war. :die Stirn runzeln:

@jvanraaij @yaggytter danke.

Da nach unserer Untersuchung nichts anderes betroffen war und keine weiteren Informationen von GitHub gegeben wurden, denke ich, dass dieses Problem geschlossen werden kann. Wer schreibt dazu einen Blogbeitrag?

@lafriks Ich habe diesen Blogbeitrag innerhalb von ein paar Tagen nach dem Start gepostet - es ist eher ein Blick auf die Malware als auf das vorliegende Problem, aber ich aktualisiere ihn gerne, wenn du der Meinung bist, dass es sich lohnt, etwas zu dokumentieren 👍

Ich glaube, er möchte einen Post-Mortem-Blog-Post auf dem gitea-Blog schreiben :)

@graystevens Übrigens, Ihr Site-Hinweis-Link ist ein 404-

Da nach unserer Untersuchung nichts anderes davon betroffen war und keine weiteren Informationen von GitHub gegeben wurden ...

Als Datenpunkt, obwohl GitHub öffentlich nichts darüber gesagt hat, haben sie privat (per E-Mail) geantwortet, um effektiv zu sagen: "Danke, wir untersuchen".

Die obigen Kommentare von @jvanraaij und @yasuokav schienen auch zu helfen, da GitHub (seltsamerweise aus meinem PoV) diese speziellen Instanzen der Malware zuvor nicht gefunden zu haben scheint.

Zum Beispiel enthalten alle hier von @yasuokav aufgelisteten https://github.com/crossoverJie/SSM/issues/36

Ich werde die Mitarbeiter von GitHub erneut per E-Mail darauf hinweisen. Sie scheinen sich innerhalb weniger Tage um die Dinge zu kümmern, wenn sie direkt mit einer genauen Liste zum Einsehen kontaktiert werden.

Das ist traurig für alle anderen Projekte, aber zumindest für Gitea haben wir die Probleme hoffentlich richtig gelöst... :)

Dieses Problem wird geschlossen, da Binärdateien jetzt signiert sind und 2FA implementiert ist.