Gitea: La cuenta de Giteabot se vio comprometida

Mientras tanto, tenga cuidado al descargar nuestros binarios publicados, especialmente los de Windows, hasta nuevo aviso. Por ejemplo, vigile el tamaño de los binarios, o un final de archivo doble .exe .
Descubrimos que nuestros binarios .exe dentro de la versión 1.4.2 también fueron alterados.

Trabajamos duro para seguir todos los senderos, limpiar y volver al trabajo diario lo antes posible.

@daviian ¿ Quizás entonces es necesario firmar comunicados?

@Mauladen Gracias por su aporte. Definitivamente discutiremos esto.

¡Ay! Sí, los binarios firmados serían ideales.

@Mauladen Hemos reconstruido los binarios para la versión 1.4.2 solo para asegurarnos de que proporcionamos los seguros.

¿O te refieres a otra cosa?

Esto es normal. Regentamos 1.4.2 para reactivar CI para reconstruir binarios ya que se eliminó el binario de Windows para esa versión y se agregó uno nuevo malicioso

@daviian , tal vez @Mauladen significó que 1.4.2 release commit sin firma GPG, pero 1.4.1 fue

Aún necesito editar la lista de cambios

@axifive commit donde no gpg firmado por el usuario sino github que lo hace automáticamente (con la clave github) cuando la fusión es la misma que el autor de relaciones públicas. No lo consideraría más seguro porque si la cuenta de github estuviera comprometida, también aparecería como "verificado". Pero podríamos empezar a firmar la etiqueta a partir de ahora (para discutir). Para obtener información, estamos trabajando en la firma de binarios, ya que es más fácil modificar el binario de thzan como el árbol de confirmación de git.

Debes cargar un tarball creado por git-archive (además de los que genera github automáticamente) que firmas con signify . Puede tener una idea de cómo funciona / se ve aquí:

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

Libressl utiliza la misma tecnología.

¿Hay más información sobre esto? ¿Cuál fue la carga útil del binario? ¿Se informará a los usuarios sobre esto a través de una publicación de blog o algo? ¿Se vio comprometido alguno de los binarios de Linux? Estoy bastante preocupado por lo que estas cosas pueden haberle hecho a mis servidores. Me preocupa doblemente que solo me enteré de esto al navegar por la página del problema por casualidad en lugar de un aviso oficial en la página / blog del proyecto.

¿Es seguro actualizar la versión de Gitea 1.4.2 desde el código fuente en este momento?

En este punto, no me queda claro si solo se vieron afectados los binarios. ¿Cómo verificaste esto? ¿Están tus ramas protegidas?

shasums difieren en los binarios que descargué en 6/4 y 6/7 aunque tienen el mismo número de bytes:

$ 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

¿Te apetece alojarlos en algún lugar para que la gente pueda destrozarlos?

Subió los binarios aquí: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA. Los pondré en algún lugar más permanente si es necesario.

Pregunta: ¿son solo los binarios del sitio web los que se vieron afectados o los repositorios también se vieron afectados? Pregunto porque ayer me enteré de Gitea y cloné y construí la rama v1.4.

Realmente me gustaría más información si la fuente en sí está comprometida o solo los binarios. Ejecuto un script para buscar actualizaciones / compilación desde git todas las noches y tuve la suerte de perderme esto debido al tiempo.

¿Se ha verificado que la versión 1.4.2 actual está limpia? Si sabemos que está contaminado, deberíamos extraerlo lo antes posible y ponerlo en otro lugar para su análisis, de lo contrario, la gente todavía lo descargará si no ve este problema. Estoy de acuerdo con @CountMurphy , ¿podemos agregar algo al

¿Podemos obtener hashes para comprobar si nuestros binarios se ven afectados? Mi gitea 1.4.1 (linux amd64) se ve así:
$ sha256sum gitea
d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 gitea

Acabo de descargar gitea 1.4.1 linux-amd-64 y obtuve d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851 como sha256 también

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

Para dejarlo abrumadoramente claro: nadie sabe nada y los únicos hash seguros son los que se encuentran actualmente aquí: https://github.com/go-gitea/gitea/releases

Para Gitea 1.4.2 en amd64, eso significa:

Lo siento, entendí mal https://github.com/go-gitea/gitea/issues/4167#issuecomment -395576229 en el sentido de que ambos binarios estaban comprometidos.

He editado esta publicación para eliminar cualquier ambigüedad sobre lo que realmente sabemos.

Espera: de acuerdo con este comentario (https://github.com/go-gitea/gitea/issues/4167#issuecomment-395576229), hay dos shas e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 desde el 4 de junio y c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d desde el 7 de junio.

¿Estamos diciendo que ambos están comprometidos o solo uno de ellos? Para que conste, el de mi servidor es e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 del 5 de junio.

@christianbundy , por favor, no

Por favor, no saque conclusiones apresuradas, espere una respuesta del miembro del equipo.

Lo siento, pensé que un miembro del equipo publicaría los hashes de archivo de inmediato y no me di cuenta de que la información provenía de otra persona que también estaba en la oscuridad. ¿Es este el canal correcto para estar atento a los últimos desarrollos? Apagué mi servidor y necesito más información para saber si me he infectado.

Veo sus ediciones tachando la entrada que señalé. SIN EMBARGO, ¿no es demasiado pronto para sacar conclusiones? ¿Cómo sabemos con certeza que e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 está bien?

Todavía nos faltan algunos datos (probablemente no exhaustivos):

• [] ¿Qué binarios se vieron comprometidos y cuáles son sus sumas de comprobación?
• [] ¿Cuándo se vio comprometida la cuenta del bot?
• [] ¿El repositorio de origen está comprometido (esto podría ser fácil de verificar si tiene una versión del repositorio clonada de algún tiempo atrás, entonces tal vez pueda verificar las diferencias o evidencia de empujes forzados).

Tengo:

# 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

Con sha256sum d8cfa0d39da70497f1f75e519e4fee33e5ee7c0de88919bdfe46a8b0d38af851

y acabo de descargar gitea-1.4.2-linux-amd64 :

# 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

Con sha256sum c843d462b5edb0d64572b148a0e814e41d069d196c3b3ee491449225e1c39d7d que coincide con el archivo .sha256 proporcionado: gitea-1.4.2-linux-amd64: OK que debería ser seguro. (¿Derecha?)

[...] Hemos reconstruido los binarios para la versión 1.4.2 solo para asegurarnos de que proporcionamos los seguros. [...]

Subí gitea-1.4.2-linux-amd64 para su análisis aquí , pero en realidad no dice nada obvio.

Voy a ver este problema y mantener mi instalación de gitea fuera de línea por el momento.

¿Cómo sabemos con certeza que e14e54f334ce022d2026d0801da1ed1bf3bcba751b16fb290bae4d10d14482e9 está bien?

@shuhaowu Dije que c843d462 estaba bien, no e14e54f3 . Sabemos esto porque ese es el archivo que se está sirviendo actualmente en GitHub, que han reconstruido recientemente.

Si se reconstruyó 1.4.2, debe firmarse y verificarse como las otras versiones válidas. No hacerlo solo aumenta la confusión.

@xcolour

Subió los binarios aquí: https://send.firefox.com/download/a5dc9a9335/#_k9e4Cu2r4pPNDrsS1T2CA

La única diferencia entre estos dos binarios es que alrededor de 2000 instancias de movabsq $63663754793, %rcx fueron reemplazadas por movabsq $63663969431, %rcx . No puedo decir exactamente qué cambia de comportamiento, pero creo que es muy poco probable que sea suficiente para ser malicioso.

Tal vez lanzar una nueva versión 1.4.3 (¿firmada?) Con el código seguro conocido, ¿o eso confundiría más las cosas?

@justinclift Me gusta esa idea, también una publicación de blog y algo en el archivo README sobre la situación ayudaría a aclarar las cosas.

@ espaguetis2514

Por un lado, tiene razón: las diferencias entre los dos binarios _esos_ son fáciles de ver.

Por otro lado, el equipo de Gitea no ha publicado realmente qué binarios se vieron afectados, no ha publicado ningún hash SHA256 o realmente ha dicho _cualquier cosa_ que nos ayude a comprender el compromiso.Como han señalado otros, no tenemos suficiente información para determinar. qué pasó y quién se ve afectado.

Me frustra señalar que probablemente deberíamos asumir lo peor y esperar los pasos de diagnóstico del equipo central. Dicho esto, agradezco que publiques el diff desmontado.

¿Es esto lo que estás buscando? https://github.com/go-gitea/gitea/issues/4167#issuecomment -395579466

¡Gracias por la actualización @lafriks !

He actualizado la descripción del problema con información adicional. No fue tan malo como podría haber sido. Queríamos ser lo más transparentes posible, así que creamos este problema tan pronto como limpiamos y arreglamos todo y como era la primera vez que sucedía algo así, probablemente deberíamos haber dado más información más rápido, lo siento por causar confusión.

@lafriks ¡ Gracias por la actualización! ¿Podrías publicar tu clave PGP que podamos usar en el futuro para verificar las confirmaciones?

Las etiquetas

Las versiones se firmarán con la clave GPG que se creará antes de la versión 1.5.0, la publicaremos en README.md, gitea docs y en la publicación del blog.

Como usuario 386, puedo confirmar que el binario gitea-1.4.1-linux-386 actualmente disponible en la página de lanzamientos coincide con una versión que descargué el 4 de junio ( cf6344b4 ).

como todos los RP se fusionaron usando Squash & Merge, no están firmados (o tal vez firmados por la magia de GitHub :))

No uses el botón de combinación, eso es básicamente inseguro y una clave gpg aleatoria. Fusionar localmente y empujar la fusión.

@mappu gitea v1.4.1 no se ha visto afectado y ahora se ha vuelto a publicar v1.4.2.

Debes cargar un tarball creado por git-archive (además de los que genera github automáticamente) que firmas con signify.

En realidad, ni siquiera tiene que crear los archivos y volver a subirlos. Puede firmar el que creó GitHub, porque se puede hacer de forma reproducible.

Aquí hay un pequeño script para eso: https://github.com/rugk/gittools/blob/master/signrelease.sh

@rugk Guión de aspecto útil. :sonrisa:

¿Algún miembro del equipo que contribuyó obtuvo un archivo de 1.4.2 antes del descubrimiento de la infracción?

Parece que ha dejado a mucha gente sin saber si este binario ha sido alterado o no para alguna versión de Linux, lo cual es un dato bastante importante considerando:

1) La mayoría de las implementaciones se realizarán en pilas de Linux.

2) Las pilas de Linux no están acostumbradas a los troyanos binarios y, por lo general, no son adecuadas para las mejores herramientas para detectar mediante programación el código sospechoso que ya se está ejecutando en el sistema.

Si bien me gustaría creer que este fue un simple ataque dirigido a Windows y nada más, el hecho de que apuntaron a este repositorio específico solo unos días en un aumento dramático en el crecimiento de la base de usuarios parece indicativo de un esfuerzo más bien orquestado. Dudo mucho que cualquiera que supiera a qué se dirigían y cómo llevar a cabo este tipo de cosas hubiera dejado pasar una oportunidad tan propicia para infectar a tantos hosts como fuera posible.

@stanier dl.gitea.io no se vio afectado y hemos verificado que no se manipularon otros binarios

Entonces eso explica por qué nuestro webproxy se negó a descargar la última imagen de gitea de hub.docker.com ...

@lafriks Entonces, ¿puedes confirmar que c843d462 y e14e54f3 son seguros? Si el CI proporcionó una compilación con una firma diferente, entonces algo debe haber cambiado en el código fuente o en los parámetros que el compilador usó para la compilación. Es un tecnicismo menor en sí mismo, pero nunca se dijo directamente aquí si el adversario había alterado o no los binarios de Linux 1.4.2, solo los respectivos binarios .exe mencionados en el comentario de @daviian.

Solo para aclarar, estoy preguntando sobre los binarios de la página de lanzamiento del repositorio de GH, no sobre dl.gitea.io, entiendo que no se manipuló nada fuera del repositorio de GH.

Las pilas de Linux no están acostumbradas a los troyanos binarios y, por lo general, no son adecuadas para las mejores herramientas para detectar mediante programación el código sospechoso que ya se está ejecutando en el sistema.

Hmmm, ¿no tienen la mayoría de los administradores de paquetes (y similares) la posibilidad de verificar al menos las sumas de comprobación sha *? No necesariamente solo para detectar malware, sino como "verifiquemos que la descarga no esté dañada".

@justinclift sí, pero eso solo se aplica a los binarios instalados a través del administrador de paquetes. El problema en cuestión aquí se relaciona con una descarga directa desde GitHub, que no tiene ninguna detección de malware incorporada a mi leal saber y entender.

Ahhh. El término "pilas de Linux" me desconcertó, ya que estoy más acostumbrado a que las descargas directas sean cosas simples y únicas (por ejemplo, cuando se hacen prototipos), en lugar de algo que haría una solución automatizada. No hay problema. :sonrisa:

@stanier la construcción fue rehecha por drone para despejar todo. Go no proporciona el mismo binario cada vez que compila el binario, ya que alguna variable podría cambiar (como el tiempo de compilación), por lo que es normal que el hash sea diferente.
Obtuve todos los archivos binarios durante la investigación y puedo proporcionar hash tan pronto como llegue a mi computadora personal.

Para todos, dejen de discutir sobre los rumores y brinden comentarios constructivos.
Entiendo que te preocupas por tu seguridad y nosotros nos preocupamos mucho por ella (ya que también estamos en tu lugar como usuario de gitea). Actualmente se cambió el acceso y ya no hemos visto ninguna actividad sospechosa. Hemos hecho esta edición para informar lo antes posible para ser transparentes y poder recibir aportes de cualquier dato útil para investigar o lugar perdido ya que nadie es perfecto.
Haremos una autopsia para explicar lo que sucedió y definitivamente hemos pensado en acciones para evitarlo en el futuro.
Si este tema se vuelve loco, creo que tendremos que cerrar para mantener solo información útil y concisa y enviar el debate a la discordia donde debería ir.

Para evitar una situación como esa en el futuro, comenzaremos a firmar todos los binarios con la próxima versión. He creado un complemento para Drone que puede encontrar en https://github.com/drone-plugins/drone-gpgsign (la documentación para este complemento debe hacerse) que firmará todos los binarios, se cargará la clave pública al servidor de descargas y a un servidor de claves, entonces siempre podrá verificar los binarios de una manera confiable.

Solo para mostrarte un ejemplo de cómo se verá esto y cuáles son los resultados, puedes echar un vistazo a https://github.dronehippie.de/webhippie/ldap-proxy/49/18 y https://dl.webhippie.de / misc / ldap-proxy / master / , se cargarán archivos similares en la página de descarga de Gitea y en las versiones de GitHub.

Si cree que a este complemento le falta algo realmente importante, no dude en abrir un problema en el repositorio de complementos y puedo solucionarlo.

@sapk Gracias por la aclaración. Pido disculpas, se me olvidó por completo que el proyecto estaba basado en Golang; la mayoría de los problemas como este tienen que ver con software más antiguo, así que creo que mi mente saltó a una relación falsa. Mi error.

Empecé a echar un vistazo al binario install.exe que se cargó: https://grh.am/2018/a-look-at-the-compromised-gitea-release/

Parece que no solo Gitea se vio afectada por esto, sino también https://github.com/opencompany/www.opencompany.org/releases

Gracias por la clara explicación.

Creo que este problema es la razón principal para pasar por un empaquetado específico de la distribución. Atrae más atención al paquete y al posible código malicioso / binario (especialmente en caso de un intento tan grave). Sería genial tener al menos paquetes Debian / RedHat / Archlinux para Gitea: eso evitaría que muchas personas ejecuten un binario arbitrario en su servidor de producción :)

¿Es suficiente con PGP firmar los lanzamientos? Probablemente. Solo asegúrese de anunciar su clave pública en muchas plataformas diferentes para que, por ejemplo, comprometer su sitio web no haga que todos descarguen claves incorrectas. (Pero un paquete Debian en los backports sería <3)

(Además, ¿ compilaciones reproducibles ?)

Dado que comenzará a firmar versiones binarias, ¿podría considerar también la posibilidad de firmar las imágenes de Docker enviadas al registro?

Parece que no solo Gitea se vio afectada por esto, sino también https://github.com/opencompany/www.opencompany.org/releases

Simplemente envíe un correo electrónico a las personas de contacto directamente, en caso de que aún no estén viendo sus problemas de GitHub.

@graystevens ¿Debería contactarse al personal de pastebin para eliminar esa dirección de pastebin, o es mejor analizar completamente el malware primero para que se entienda correctamente?

Gracias a todos .. Volvería a descargar y volvería a poner mi servidor

@justinclift Informaré sobre el pegado a PasteBin ahora. Tengo una copia del contenido para que podamos recrear la salida del malware en caso de que sea necesario. Buen grito

Para ser justos, go is ahora tiene una compilación reproducible: https://blog.filippo.io/reproducing-go-binaries-byte-by-byte/
Eso tal vez cgo para sqlite y algunos build env que los hacen no reproducibles.

Solo a título informativo, la reconstrucción anterior y la lista

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

El paso de limpieza install.exe parece haber pasado por alto algunos repositorios:

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

La mayoría de estos son antiguos y no son exactamente relevantes, pero probablemente no sea una buena idea mantener el malware a mano.

@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
  

Uf, gracias. ¿Cuál es el enfoque que está utilizando para localizarlos? Parece que cualquier enfoque que haya utilizado el personal de GitHub no ha sido realmente 100% efectivo. :ceñudo:

@jvanraaij @yaggytter gracias.

Como después de nuestra investigación, nada más se vio afectado y GitHub no proporcionó más información, creo que este problema se puede cerrar. ¿Alguien puede escribir una publicación de blog sobre esto?

@lafriks Publiqué esta publicación de blog un par de días después de que todo esto comenzara: es más una mirada al malware que al problema en cuestión, pero me complace actualizarlo si cree que vale la pena documentar algo 👍

Creo que quiere escribir una publicación de blog post-mortem en el blog de gitea :)

@graystevens Por cierto, el enlace de su

Como después de nuestra investigación, nada más se vio afectado y GitHub no proporcionó más información ...

Como dato, aunque GitHub no ha dicho nada sobre esto en público, en privado han respondido (por correo electrónico) para decir efectivamente "Gracias, estamos investigando".

Los comentarios anteriores de @jvanraaij y @yasuokav también parecieron ayudar, ya que (extrañamente, desde mi punto de vista) GitHub no parece haber encontrado esas instancias particulares del malware antes de eso.

Por ejemplo, todos los repositorios enumerados por @yasuokav aquí todavía tienen el malware: https://github.com/crossoverJie/SSM/issues/36

Enviaré un correo electrónico al personal de GitHub nuevamente para señalarlo. Parece que arreglan las cosas en unos pocos días cuando se les contacta directamente con una lista exacta para mirar.

Esto es triste para todos los demás proyectos, pero al menos para Gitea hemos resuelto los problemas correctamente, con suerte ... :)

Cerrando este problema ya que los binarios ahora están firmados y se implementa 2FA.