MANTRA Chain ponownie online — programiści szukają odpowiedzi na temat cichych zmian w kodzie

MANTRA Chain przywróciła produkcję bloków w mainnecie na wersji v8.4.0 — sześć dni po tym, jak incydent bezpieczeństwa wymusił zatrzymanie całego łańcucha. Obiecany raport techniczny nie został jeszcze opublikowany, przez co niewyjaśnione pozostają wykorzystanie zależności nadrzędnej oraz aktywność wewnątrz dwóch portfeli zarządzanych przez projekt.

Zgodnie z oficjalną osią czasu incydentu mainnet wznowił działanie około godziny 05:30 UTC 22 sierpnia. Łańcuch poinformował, że między zatrzymaniem a restartem nie doszło do rollbacku ani zmiany stanu, salda użytkowników nie zostały zmienione, a posiadacze tokenów nie musieli podejmować żadnych działań.

Zespół oznaczył incydent jako rozwiązany 24 sierpnia, ale ponownie oświadczył, że raport post-mortem zostanie opublikowany w ciągu najbliższych dni. Przy sprawdzeniu 27 sierpnia ani aktualna strona statusu, ani oficjalny kanał ogłoszeń nie zawierały odnośnika do tego raportu.

MANTRA poinformowała, że jej analiza wykazała, iż incydent objął dwa portfele zarządzane przez MANTRA, a żadne środki użytkowników, giełd ani partnerów nie zostały naruszone. Publiczny opis nie wskazuje jednak adresów portfeli, hashy transakcji, kwot ani technicznych kroków wykorzystanych w ataku.

Gdy 21 sierpnia po raz pierwszy informowano o zatrzymaniu sieci, testy poprawki były nadal w toku. Powrót sieci rozwiązuje problem przerwy operacyjnej, lecz metoda atakującego oraz ocena powstrzymania incydentu przedstawiona przez MANTRA pozostają nieujawnione.

Dla operatorów węzłów publiczny zapis kodu rodzi natychmiastowe, praktyczne pytanie: która kompilacja v8.4.0 jest aktualnie uruchomiona. Bieżąca strona wydania wskazuje pełny commit 5c08d7bd9e2619952707dae1258d2a30bf024721, a MANTRA ostrzega, że tag został ponownie wypchnięty podczas procesu przywracania, i zaleca operatorom jego ponowne pobranie.

Tego rodzaju jednoznaczność na poziomie wersji ma znaczenie przy przywracaniu po incydentach, ponieważ walidatorzy i zespoły infrastrukturalne zazwyczaj opierają się na tagach wydań i changelogach, aby potwierdzić, że po awaryjnym restarcie pracują na właściwej kompilacji. W tym przypadku ścieżka wydania jest publiczna, ale uzasadnienie zmian w kodzie nie zostało w pełni udokumentowane.

Changelog wydania wymienia pośrednie podbicie wersji forka MANTRA EVM z v0.6.0-v8-mantra-3 do v0.6.0-v8-mantra-4. Finalny, otagowany plik go.mod zastępuje tę zależność forkiem łańcucha v0.6.2-v8-mantra-1.

Finalny upgrade handler dodaje jeden adres do listy blokowania i wyłącza poprzez mechanizm circuit breaker trzy komunikaty Cosmos służące do tworzenia kont vestingowych. Zmiany te opisują wdrożone środki zaradcze, natomiast sama ścieżka ataku pozostaje nieujawniona.

Dlaczego błąd ICS20 z marca pozostaje dla użytkowników MANTRA jedynie teorią

Marcowy komunikat doradczy Cosmos Labs opisywał krytyczną lukę w prekompilacie ICS20, wskazywał, że znane dotknięte łańcuchy wdrożyły środki zaradcze lub przeprowadziły aktualizację, i wymieniał Mantra wśród współtwórców działań naprawczych. Jego oś czasu kończy się na marcowym ujawnieniu, przez co sierpniowy incydent mieści się poza jego udokumentowanym zakresem.

Sprawia to, że brakujący raport post-mortem ma szczególne znaczenie dla czytelników próbujących oddzielić potwierdzone fakty od odniesień do starszych podatności: publiczny zapis pokazuje restart, otagowaną kompilację i ograniczony zestaw środków zaradczych, ale nie ciąg zdarzeń, które doprowadziły do zatrzymania sieci. Dopóki MANTRA nie opublikuje obiecanego raportu technicznego, użytkownicy mogą zweryfikować restart, dokładny finalny kod oraz deklarowany wpływ incydentu, ale nie adresy portfeli, hashe transakcji, kwoty ani techniczne wyjaśnienie niezbędne do powiązania tego incydentu z jakąkolwiek wcześniejszą luką.

Źródło | Powiązany artykuł