Liquid Network se ha acercado a la restauración de las operaciones de peg out después de iniciar una auditoría de seguridad independiente de Elements v23.3.4 y coordinar cambios en las claves de autorización utilizadas en el proceso de retiro.
Resumen
- Liquid Network ha iniciado una auditoría de seguridad externa independiente de Elements v23.3.4 antes de restaurar las operaciones de peg out.
- La Liquid Federation está reemplazando las entradas PAK existentes y asegurando que las claves de peg out estén debidamente protegidas en almacenamiento en frío.
- Los peg outs permanecen suspendidos, y Liquid aún no ha proporcionado una fecha firme para cuándo se reanudarán las operaciones.
- El último trabajo de seguridad sigue al exploit de septiembre que llevó a que se retiraran aproximadamente 4,000 BTC de la reserva de la federación.
Liquid Network dijo en su actualización del ecosistema del 28 de septiembre que una auditoría de seguridad externa de Elements v23.3.4 está ahora en marcha como parte de su trabajo para restaurar de forma segura los peg outs tras el incidente de seguridad de septiembre de la red.
Al mismo tiempo, la Liquid Federation está actualizando su lista de Claves de Autorización de Peg out, o PAK. Las entradas existentes están siendo reemplazadas y la federación está trabajando para garantizar que todas las claves de recepción de Bitcoin asociadas con los peg outs estén debidamente protegidas en almacenamiento en frío.
Liquid no proporcionó una fecha para que se reinicien los retiros. La red dijo que la auditoría y los cambios de PAK son pasos hacia la reanudación de operaciones seguras de peg out, y se espera otra actualización sobre el proceso de restauración en breve.
La auditoría de Liquid Network se centra en Elements v23.3.4
Elements v23.3.4 fue lanzado a principios de este mes para abordar el fallo de software explotado durante el incidente del 6 de septiembre, cuando un atacante creó aproximadamente 4,000 LBTC sin respaldo y utilizó el proceso normal de peg out de Liquid para retirar Bitcoin de la reserva de la federación.
La última auditoría externa añade otra revisión de ese lanzamiento antes de que se vuelvan a activar los peg outs.
Elements es la plataforma blockchain de código abierto detrás de Liquid. La red utiliza transacciones confidenciales, que ocultan los montos de las transacciones mientras que las pruebas criptográficas permiten a los nodos verificar que esos montos son válidos.
La evaluación posterior al incidente de Liquid dijo que la vulnerabilidad involucraba la forma en que Elements almacenaba en caché los resultados de la verificación de rangeproof. Un cambio anterior había eliminado parte del contexto de la transacción de la clave de caché, creando un fallo de consenso que podría permitir que un resultado de verificación en caché se reutilizara bajo circunstancias diferentes.
Una corrección posterior abordó el problema identificado inicialmente, pero persistía un segundo problema relacionado con cómo se combinaban los campos en la clave de caché. El atacante del 6 de septiembre explotó esa segunda debilidad para crear una salida cuyo valor no estaba respaldado por sus entradas.
Elements v23.3.4 cambió la forma en que se construyen las claves de caché de rangeproof y prueba de sobreyección al serializar cada campo con un prefijo de longitud. Liquid dijo que el cambio evita que diferentes conjuntos de entradas produzcan la misma clave de caché mediante el método de colisión utilizado en el ataque.
La corrección reforzada se fusionó en la rama de lanzamiento Elements 23.3.x el 8 de septiembre y Elements v23.3.4 se publicó al día siguiente.
Como fue cubierto previamente por crypto.news, Liquid reanudó la producción de bloques después de que los nodos funcionarios recibieran las actualizaciones de software requeridas, mientras que las operaciones de peg permanecieron deshabilitadas.
Las transacciones regresaron posteriormente a la red mientras Liquid avanzaba a través de su proceso de recuperación por etapas. Los peg outs han permanecido suspendidos mientras la federación completa el trabajo en la parte del sistema que libera BTC de la reserva.
La Liquid Federation está reemplazando las entradas PAK
La segunda parte de la actualización del 28 de septiembre se centra en el sistema PAK utilizado para autorizar peg outs de Liquid a Bitcoin.
Bajo la arquitectura de Liquid, las entradas PAK contienen dos claves con funciones separadas. Un componente fuera de línea se deriva de la billetera de recepción de Bitcoin de un miembro, mientras que una clave en línea firma las solicitudes de peg out.
Los nodos Functionary utilizan el componente fuera de línea para verificar que el destino de Bitcoin pertenece a una entrada PAK registrada. Las claves privadas que controlan el Bitcoin receptor están destinadas a permanecer fuera de línea.
El componente en línea realiza un trabajo diferente. Su clave privada opera en un nodo de Elements porque se necesita para firmar las solicitudes de liberación de Bitcoin a través del proceso de peg out.
La evaluación del incidente de Liquid dijo que la disposición de la billetera fuera de línea tiene como objetivo proporcionar otra capa de protección si falla un sistema upstream. El Bitcoin liberado a través de un peg out permanecería en una billetera fría y requeriría una acción separada antes de poder ser transferido.
El incidente del 6 de septiembre expuso una debilidad en esa protección junto con la vulnerabilidad de consenso de Elements.
Después de crear los LBTC sin respaldo, el atacante utilizó SideSwap, un miembro de Liquid Federation con un PAK, para procesar el peg out. SideSwap recibió aproximadamente 4,000 LBTC a través de su servicio antes de que los firmantes de la federación liberaran aproximadamente 3,996 BTC en Bitcoin.
La evaluación de Liquid dijo que dos problemas separados permitieron que se tomaran los Bitcoin: las vulnerabilidades de consenso de Elements y una brecha en la configuración del proceso de firma PAK de un miembro de la federación.
SideSwap ha dicho que la federación sabía que su clave de autorización de peg out operaba en línea y que este arreglo había sido visible en sus peg outs durante años. La compañía dijo que no se le había dicho que cambiara cómo operaba la clave o que suspendiera los peg outs antes del incidente.
SideSwap dijo que estaba revisando cómo se mantiene su clave de autorización, así como los límites y controles aplicados antes de los pagos, y no restauraría sus servicios de peg hasta que tanto ella como la federación estuvieran satisfechas con la nueva configuración de seguridad.
La última actualización de Liquid ahora confirma que la federación está reemplazando las entradas PAK existentes y trabajando para garantizar que las claves de peg out relevantes se mantengan en almacenamiento en frío antes de que se reanuden los retiros.
Los peg outs siguen siendo la operación restringida final
La actividad normal de transacciones regresó a principios de septiembre, pero el peg de Bitcoin ha permanecido sujeto a restricciones durante la recuperación.
Liquid inicialmente detuvo los nodos puente el 6 de septiembre después de que el atacante explotara la falla de Elements. La producción de bloques se reanudó el 9 de septiembre utilizando la cadena corregida, seguida por el regreso de la actividad de transacciones de usuarios mientras la federación monitoreaba la red.
Los peg outs permanecieron deshabilitados durante todas esas etapas.
El incidente original resultó en aproximadamente 4,000 BTC saliendo de la reserva de la federación después de que el atacante creara LBTC sin respaldo. Los actores se identificaron como sombreros blancos a través de un mensaje en cadena y luego devolvieron 3,400 BTC a la billetera de la federación después de que Blockstream confirmara que los nodos afectados habían sido parcheados.
Aproximadamente 602 BTC permanecen sujetos a esfuerzos de recuperación, según la última evaluación detallada del incidente de Liquid.
Blockstream luego rechazó una demanda de recompensa vinculada a los fondos restantes, diciendo que trabajaría con las fuerzas del orden, intercambios, especialistas forenses y otros proveedores de servicios para perseguir su recuperación.
El plan de recuperación por etapas de Liquid exige que las operaciones de peg se reanuden después de que se haya restaurado el estado de la red y se haya completado el trabajo de seguridad requerido. La auditoría externa de Elements v23.3.4 y el reemplazo de las entradas PAK son los últimos pasos divulgados bajo ese proceso.
