Udukuzi wa Binance: Jinsi wahandisi wawili walivyonaswa na jinsi ya kuzuia shambulio kama hilo

Udukuzi wa Binance wa tarehe 29 Oktoba 2026, unaokadiriwa kugharimu takriban dola bilioni 6.3, umefichua mbinu ya kupenya yenye kutia wasiwasi mkubwa. Washambuliaji hawakuanza kwa kuvunja ulinzi wa kriptografia wa wallets. Inadaiwa kwanza waliathiri kompyuta za wahandisi, wakatumia vibaya ruhusa zao za kikazi, kisha wakageuza mifumo ya ndani iliyowezesha kuidhinisha miamala.

Tarehe 3 Novemba, Binance ilieleza kwa kina operesheni iliyokuwa imeandaliwa kwa miezi kadhaa. Mhandisi mmoja alikuwa ameweka programu iliyoathiriwa mwezi Juni. Mwingine alinasa mwezi Septemba kupitia mchakato bandia wa ajira. Inadaiwa baadaye wadukuzi walitumia zana ya ndani ya akili bandia kusonga ndani ya mifumo ya kampuni, kabla ya kuiba vitambulisho na kutekeleza shambulio.

Kwa ufupi

• Binance inaeleza uvamizi wa hatua kadhaa ulioanza kabla ya wizi wa tarehe 29 Oktoba.
• Matumizi mabaya ya ruhusa za kuidhinisha hayathibitishi peke yake kuvuja kwa funguo binafsi.
• Ulinzi unapaswa kutenganisha kompyuta za kazi, uwekaji wa mifumo na maamuzi ya kusaini miamala.

1. Binance iliingiliwa kwa miezi kadhaa

Juni 2026: Programu iliyoathiriwa yafungua mlango wa kwanza

Shambulio lilianza miezi kadhaa kabla ya wizi wa cryptocurrency. Linaonyesha kwa nini usalama wa wallet ya crypto unategemea pia mifumo inayotayarisha operesheni.

Kisa hiki kinahitaji uchambuzi wa kina wa kiufundi. Mhojiano wa kawaida wa ajira unawezaje kuhatarisha jukwaa linalolinda mabilioni ya dola? AI ilihusika kwa kiwango gani? Kwa nini mifumo ya usalama haikuzuia uhamisho mara moja? Na muhimu zaidi, ni ulinzi gani ungezuia kompyuta ya kazi iliyoathiriwa kugeuka kuwa janga la kifedha?

Kulingana na taarifa ya briefing iliyochapishwa na CoinDesk, Binance inasema wadukuzi walitumia vibaya ruhusa zake za ndani. Katika taarifa yake rasmi ya tarehe 30 Oktoba, jukwaa lilisema halikuwa limepata ushahidi wa kuvuja kwa funguo binafsi.

Mwezi Juni 2026, mhandisi wa Binance alikuwa akitafuta zana inayohusiana na akili bandia. Katika utafutaji huo, aliweka sehemu ya programu iliyoathiriwa iliyohusishwa na Homebrew.

Homebrew ni package manager inayotumiwa sana kwenye macOS na Linux. Huwezesha developers kusakinisha programu, libraries na zana za programming kupitia terminal, bila kupakua na kusanidi kila programu kwa mkono.

Kwa mfano, amri kama brew install ikifuatiwa na jina la programu huomba programu hiyo isakinishwe.

Tatizo si lazima litokane na Homebrew yenyewe. Washambuliaji wanaweza kugeuza mnyororo wa usambazaji wa zana, kutoa package hasidi au kubadilisha chanzo ambako programu inapakuliwa.

Katika kisa cha Binance, taarifa za umma zinaonyesha kuwa mhandisi huyo alisakinisha sehemu iliyobadilishwa. Hata hivyo, hazitoshi kuthibitisha kuwa miundombinu rasmi ya Homebrew ilidukuliwa.

Binance inasema iligundua programu hasidi na kubadilisha kompyuta. Hata hivyo, washambuliaji walikuwa tayari wamepata taarifa muhimu kuhusu majukumu ya mhandisi huyo na wenzake waliokuwa wakifanya kazi kwenye wallets za cryptocurrency.

Hii ni tofauti muhimu katika usalama wa mtandao. Kuondoa malware hakuondoi taarifa ambazo mshambuliaji tayari amekusanya.

Mdukuzi anaweza kuhifadhi taarifa kuhusu muundo wa kampuni, majina ya wafanyakazi, zana za ndani, taratibu za deployment au uhusiano kati ya timu mbalimbali. Taarifa hizo humsaidia kuandaa shambulio lililolengwa zaidi.

Septemba: Ajira bandia inamnasa mhandisi wa pili

Miezi michache baadaye, mhandisi mwingine wa software alipokea ofa ya kazi kupitia jukwaa halisi la ajira.

Mtu aliyewasiliana naye alijitambulisha kama project manager wa kampuni. Mtu mwingine aliyeigiza nafasi ya mkuu wa rasilimali watu akaandaa mahojiano ya video. Mwajiri huyo bandia pia alishiriki profile ya mitandao ya kijamii iliyoambatanishwa na picha binafsi.

Lengo lilikuwa kujenga uhusiano unaoaminika.

Baadaye, mahojiano ya pili yaliandaliwa na mtu aliyewasilishwa kama mkurugenzi mkuu wa kampuni.

Baada ya mazungumzo hayo, mwombaji alialikwa kupakua code repository iliyokuwa na zoezi la kiufundi.

Hatua hii ni ya kawaida katika ajira za IT. Waombaji wakati mwingine huombwa kuchunguza mradi, kurekebisha makosa, kuandika tests au kutengeneza feature.

Wadukuzi walitumia hasa utaratibu huo.

Repository hiyo ilikuwa na malware ambayo Binance inasema ilipita ulinzi wa kompyuta ya kikazi. Taarifa ya CoinDesk inatumia neno “zero-day malware”. Kauli hiyo peke yake haitoshi kutambua vulnerability maalumu au nambari ya CVE. Taarifa za umma zilizochunguzwa hazielezi utaratibu uliowezesha kukwepa ulinzi wa kompyuta hiyo.

Mtego ulifanikiwa kwa sababu mhandisi alidhani alikuwa anafanya zoezi halali la kikazi. Hakujaribu kukwepa usalama wa Binance; alikuwa akijibu ombi lililofanana na hatua ya kawaida ya ajira.

Hii ndiyo huitwa social engineering: kumshawishi mtu mwenyewe kutekeleza hatua inayorahisisha uvamizi.

Oktoba: Wadukuzi watumia AI kusonga mbele

Tarehe 20 Oktoba, kulingana na maelezo ya mkuu wa usalama wa Binance, washambuliaji walitumia kompyuta iliyoathiriwa katika mchakato huo bandia wa ajira pamoja na zana ya ndani ya AI kufikia mifumo ya wahandisi wawili waliokuwa wakifanyia kazi wallets.

Taarifa hii ni muhimu sana.

Hapa si suala la chatbot ya umma ambayo wadukuzi waliuliza jinsi ya kuiba cryptocurrency. Taarifa zilizoripotiwa zinaashiria matumizi ya zana ya ndani katika uvamizi ambao tayari ulikuwa umeanza.

AI assistant iliyounganishwa na mazingira ya kikazi inaweza, kulingana na ruhusa ilizopewa, kusoma code, kutafuta files, kuwasiliana na zana za development au kutekeleza baadhi ya operesheni.

Ikiwa kompyuta inayoiendesha imeathiriwa, uwezo huo unaweza kuwa na manufaa kwa mshambuliaji.

Hata hivyo, Binance haijaeleza hadharani amri zote zilizotekelezwa na zana hiyo ya AI, wala haijathibitisha kuwa zana hiyo ilifanya maamuzi hasidi kwa kujitegemea.

Kwa hiyo, si sahihi kusema AI iliidukua Binance peke yake. Wadukuzi ndio waliotekeleza shambulio. AI inadaiwa kuwa chombo kilichorahisisha kusonga kwao ndani ya mifumo.

29 Oktoba: Wizi watekelezwa

Tarehe 29 Oktoba, washambuliaji waliingia katika hatua ya kifedha.

Kulingana na Binance, walitumia kompyuta iliyoathiriwa na vitambulisho vilivyoibiwa kutoka kwa mhandisi mwingine kuweka container na kutekeleza script hasidi.

Container ni mazingira ya software yanayowezesha programu kufanya kazi pamoja na dependencies zake. Hutumiwa sana ku-deploy huduma za IT kwa namna inayoweza kurudiwa.

Katika kampuni kama Binance, baadhi ya huduma za ndani huwasiliana na miundombinu inayosimamia miamala na wallets.

Saa 20:05 UTC, fedha zilianza kutoka. Washambuliaji walitumia hasa kipengele cha Ethereum kinachoitwa EIP-7702 kugeuza ruhusa za utekelezaji za wallet iliyounganishwa na intaneti.

Uondoaji unaohusishwa na utaratibu huo ulizuiwa kikamilifu karibu saa 00:10 UTC, tarehe 30 Oktoba, kulingana na maelezo yaliyoripotiwa na CoinDesk.

Mfuatano wa uvamizi, kulingana na Binance

1. Juni 2026: Mhandisi wa kwanza aliathiriwa na programu iliyobadilishwa.
2. Septemba 2026: Mhandisi wa pili alinasa katika ajira bandia.
3. 20 Oktoba: Kusonga kuelekea mifumo ya timu ya wallets kwa msaada wa zana ya ndani ya AI.
4. 29 Oktoba: Kutumia vitambulisho vilivyoibiwa na ku-deploy script hasidi.
5. 29–30 Oktoba: Uhamisho usioidhinishwa, kudhibiti tukio na operesheni za kufungia assets.
6. 3 Novemba: Binance ilitangaza hadharani mfuatano wa kina zaidi wa shambulio.

2. Jinsi wadukuzi walivyopita ulinzi wa wallets

Kuibiwa kwa deployment token si sawa na kuibiwa kwa private key

Ili kuelewa shambulio hili, lazima tutofautishe vitu vitatu vinavyochanganywa mara kwa mara: credentials za kikazi, deployment tokens na private keys za crypto wallets.

Private key ni siri ya kriptografia inayowezesha kusaini miamala. Mwenye kuimiliki anaweza, kulingana na aina ya wallet na kanuni zake, kuidhinisha uhamisho wa fedha.

Deployment token ni tofauti. Hutumika kumthibitisha mtumiaji au huduma kwenye miundombinu ya IT ili kutekeleza operesheni fulani, kama kuchapisha toleo jipya la programu, kuanzisha container au kusasisha huduma.

Token hiyo inaweza kuwa nyeti sana ikiwa huduma inayofikiwa inahusika na uchakataji wa miamala ya kifedha.

Hebu fikiria benki yenye vault inayolindwa na funguo kadhaa. Wafanyakazi huenda wasiwe na ufikiaji wa moja kwa moja wa funguo hizo. Hata hivyo, hutumia mfumo wa IT unaotayarisha operesheni, kuomba idhini na kupeleka maagizo kwenye vault.

Mdukuzi akifanikiwa kuutawala mfumo huo, anaweza kujaribu kuufanya uandae au uidhinishe operesheni ya ulaghai.

Hii ndiyo hatari iliyoonyeshwa na kisa cha Binance.

Taarifa zilizochapishwa zinaeleza matumizi ya vitambulisho vilivyoibiwa kuweka container na kutekeleza script hasidi. Hata hivyo, bado haziwezeshi kuonyesha kikamilifu jukumu la kila token katika mnyororo wa uvamizi.

Kwa hiyo, ni lazima tuepuke kurahisisha jambo kwa njia inayopotosha: kuibiwa kwa deployment token hakumaanishi moja kwa moja ruhusa ya kumwaga fedha zote kutoka kwenye wallet.

Ili shambulio lifanikiwe, masharti mengine lazima yatimizwe, yakiwemo ruhusa zilizopitiliza, udhaifu katika kuthibitisha operesheni au kuathirika kwa vipengele vinavyoaminika.

Kwa nini MPC haitoshi kuthibitisha nia halali

Binance hutumia pia mifumo ya multi-party computation, inayojulikana kama MPC, kulinda baadhi ya operesheni za kriptografia.

Kanuni yake ni kugawanya mchakato wa kusaini kati ya pande kadhaa, kama inavyoelezwa na NIST kuhusu threshold cryptography. Haitakiwi kuchanganywa na multisig inayotumia funguo kadhaa tofauti.

Badala ya kuhifadhi private key nzima kwenye kompyuta moja, mfumo huwezesha vipengele kadhaa kushiriki katika kutengeneza sahihi halali, bila lazima kuunda upya key hiyo katika sehemu moja.

Huu ni ulinzi muhimu.

Hata hivyo, hautatui matatizo yote.

Mshambuliaji akivuruga vipengele vinavyoamua ni miamala ipi isainiwe, anaweza kujaribu kufanya operesheni za ulaghai ziidhinishwe na mfumo ambao funguo zake za kriptografia bado zimelindwa.

Sahihi inaweza kuwa halali kiufundi, ilhali operesheni hiyo haiwakilishi nia yoyote halali.

Katika kisa cha Binance, shambulio pia lilitumia sifa maalumu ya Ethereum.

EIP-7702: Kipengele halali chageuzwa kutumiwa vibaya

EIP-7702 ni mageuzi ya itifaki ya Ethereum yaliyoanzishwa kupitia upgrade ya Pectra mwezi Mei 2025.

Specification ya EIP-7702 huwezesha akaunti za kawaida za Ethereum kukabidhi utekelezaji wake kwa code ya smart contract kupitia authorization iliyosainiwa. Delegation hii hudumu hadi ibadilishwe au ifutwe; haiishi yenyewe mwisho wa transaction.

Smart contract ni programu inayotekelezwa kwenye blockchain. Inaweza kutumia kanuni kiotomatiki, kuhamisha assets au kuwasiliana na contracts nyingine.

Kipengele hiki kina matumizi halali, ikiwemo kuboresha uzoefu wa watumiaji na usimamizi wa akaunti. Mageuzi haya ni sehemu ya maendeleo ya smart wallets na account abstraction.

Hata hivyo, wadukuzi walitumia utaratibu huu kupata haki za utekelezaji kwenye Binance hot wallet.

Hot wallet hubaki imeunganishwa na mifumo inayofikiwa mtandaoni ili kuchakata deposits na withdrawals kwa haraka.

Katika uchambuzi wake wa on-chain wa shambulio, TRM Labs inaeleza autorisations kadhaa za EIP-7702 zilizokuwa zimesainiwa mapema, ili moja litumike wakati unaofaa.

Kwa nini autorisations kadhaa?

Kwenye Ethereum, miamala ya akaunti hutumia counter inayoitwa nonce. Utaratibu huu husaidia, miongoni mwa mambo mengine, kuzuia matumizi ya tena ya miamala fulani.

Kwenye wallet yenye shughuli nyingi, counter hiyo hubadilika haraka.

Kuandaa autorisations kadhaa zinazoendana na thamani tofauti zinazowezekana humwezesha mshambuliaji kuendana na counter ya wallet wakati wa kutekeleza uvamizi.

Kulingana na TRM Labs, wadukuzi walikuwa wameandaa autorisations 50 zilizofunika mfululizo wa thamani za nonce. Moja kati yake iliweza kutumika.

Utaratibu huo baadaye uliwezesha kugeuza utekelezaji wa wallet na kuhamisha assets zake.

Hii haimaanishi kuwa EIP-7702 yenyewe ni security flaw. Ni kipengele ambacho autorisations zake lazima zilindwe kwa umakini mkubwa.

Kwa nini kusimamisha withdrawals hakukutosha mara moja

Jukwaa la crypto linapogundua udukuzi, hatua yake ya kwanza kwa kawaida ni kusimamisha withdrawals.

Hatua hiyo kwa kawaida huwazuia watumiaji na wahalifu kuomba uhamisho mpya kupitia interfaces za kawaida.

Hata hivyo, si operesheni zote kwenye blockchain lazima zipitie interfaces hizo.

Mshambuliaji akiwa tayari amepata autorisations halali au amegeuza kipengele chenye uwezo wa kusaini transactions, wakati mwingine anaweza kuendelea kutenda moja kwa moja kwenye blockchain.

Hii ni mojawapo ya changamoto zilizokabili Binance.

CoinDesk inaripoti kuwa kufuta ruhusa hasidi kwenye Ethereum kulitatizwa na usanifu wa MPC uliotumika kulinda signatures. Kwa hiyo, kudhibiti utaratibu huo kulihitaji saa kadhaa. Uchambuzi huru wa Hypernative pia unaweka muda wa kufutwa kwa ruhusa hiyo karibu saa 00:10 UTC tarehe 30 Oktoba.

Ufafanuzi ni muhimu: taarifa za kwanza za Binance zilizungumzia kusimamishwa kwa withdrawals baada ya kuzuiwa kwa withdrawals. Maelezo ya baadaye ya kiufundi yanaonyesha hali tata zaidi kuhusu autorisations za EIP-7702. Kauli hizi zinapaswa kuwekwa katika mfuatano wake wa wakati, badala ya kuchukuliwa kama ripoti moja ya kiufundi iliyo kamili na ya mwisho.

Kiwango cha kifedha cha shambulio

Hesabu iliyotolewa kufikia 3 Novemba 2026

$6.3 bilioni

Thamani ya takriban ya assets zilizoathiriwa

$2.85 bilioni

Assets zilizogandishwa kulingana na Binance

98%

Tokens zilizoathiriwa zilizorejeshwa kulingana na kampuni

10

Blockchains zilizofuatiliwa katika uchambuzi wa TRM Labs

Takwimu zilizoripotiwa na Binance na vyombo vya habari maalumu. Kugandishwa kwa assets hakumaanishi lazima zimerejeshwa kabisa.

Binance inasema hasara za watumiaji zitalipwa na kwamba assets zilizoathiriwa zimerejeshwa kwa kiwango kikubwa kwa kutumia fedha za kampuni.

Ni lazima tutofautishe operesheni tatu za kifedha.

Ya kwanza ni kugandisha cryptocurrency. Kampuni zinazotoa stablecoins zinaweza kuzuia tokens zinazozidhibiti wakati transaction inahusishwa na shughuli ya ulaghai.

Ya pili ni kurejesha assets kikamilifu. Hilo linaweza kuhitaji taratibu za kisheria, ushirikiano wa kimataifa au kuhusika kwa platforms nyingine.

Ya tatu ni kuwalipa waathiriwa au kujaza upya reserves kwa kutumia fedha za kampuni yenyewe.

Kwa hiyo, jukwaa linaweza kuwalinda wateja dhidi ya hasara ya kifedha bila kuwa limepata tena cryptocurrency zilizoibiwa awali.

Nani yuko nyuma ya shambulio?

Katika tahadhari iliyochapishwa tarehe 31 Oktoba, FBI ilihusisha operesheni hiyo na Korea Kaskazini na kulitaja kwa jina TraderTraitor.

Kampuni zinazobobea katika kuchanganua blockchain transactions pia zimeona ufanano na mbinu za kundi la TraderTraitor, linalohusishwa na operesheni za Korea Kaskazini.

Pyongyang inakanusha madai hayo.

Kuhusisha cyberattack na mhusika kwa kawaida hutegemea mkusanyiko wa dalili: miundombinu iliyotumiwa, malware, mbinu za kupenya, mienendo ya fedha na ufanano na operesheni za awali.

Hakuwezi kuchukuliwa kuwa sawa na utambulisho wa mwisho wa kisheria wa kila mshiriki.

3. Jinsi ya kupunguza hatari ya shambulio kama hili kutokea tena

Somo muhimu zaidi la kisa hiki ni kwamba kampuni inaweza kuwa na kriptografia bora kabisa lakini bado ikawa hatarini kwa shambulio dhidi ya wafanyakazi na zana zake za development.

Ili kuzuia operesheni inayofanana, ni lazima viwango kadhaa vya usalama viimarishwe kwa wakati mmoja.

1. Tenganisha kompyuta za wahandisi

Tatizo la kwanza ni uwezekano wa kutumia kompyuta nyeti ya kikazi kusakinisha au kutekeleza code kutoka chanzo cha nje.

Katika shirika la kifedha, si kompyuta zote zinapaswa kuwa na ruhusa sawa.

Developer anayeshughulikia programu za kawaida anaweza kuhitaji kusakinisha libraries na kuendesha miradi ya nje. Mhandisi anayefanya kazi kwenye miundombinu ya kusaini transactions za wallets anapaswa kufanya kazi katika mazingira yenye vizuizi vikubwa zaidi.

Ulinzi unaweza kutegemea kutenganisha vituo viwili au environments mbili.

Development workstation

Tests, ajira, software za nje

Critical environment

Signatures, deployments, wallets

Files na programu zisizoidhinishwa hazipaswi kuhama kwa uhuru kutoka mazingira ya kwanza kwenda ya pili.

Kwa vitendo, utengano huo unaweza kupatikana kwa kutumia mashine maalumu, virtual desktops salama au mazingira yaliyotengwa ya administration.

Kanuni ni rahisi: kompyuta inayotumiwa kujaribu mradi usiojulikana haipaswi kamwe kuwa na privileges za moja kwa moja zinazohitajika kubadilisha miundombinu muhimu ya kifedha.

Hata malware ikiambukiza kompyuta ya kwanza, mshambuliaji anapaswa kukutana na kizuizi kingine huru.

2. Linda usakinishaji wa Homebrew na dependencies

Kupiga marufuku zana zote za nje kungekuwa vigumu kuendana na kazi ya developers. Kwa hiyo, ni lazima kudhibiti zinakotoka na jinsi zinavyotekelezwa, kwa kuzingatia mfumo wa SSDF wa NIST kwa secure development.

Kampuni kama Binance inapaswa hasa kutekeleza hatua zifuatazo:

• Kuruhusu repositories za software na registries zilizoidhinishwa pekee.
• Kuthibitisha uadilifu na, inapowezekana, signatures za packages zilizopakuliwa.
• Kutumia mirror ya ndani kusambaza software zilizothibitishwa.
• Kuchunguza installation scripts, hasa zinazotekelezwa kwa privileges za juu.
• Kuzuia usakinishaji wa moja kwa moja wa programu zisizojulikana kwenye kompyuta nyeti.
• Kuchanganua software dependencies na kufuatilia updates zake.

Ni lazima pia kuepuka desturi hatari ya kupakua script kutoka intaneti na kuitumia mara moja kwa ruhusa za mtumiaji au administrator.

Script inayoonekana kutokuwa na madhara inaweza kusakinisha programu nyingine, kuchukua credentials au kuanzisha mawasiliano na server inayodhibitiwa na mshambuliaji.

Udhibiti unapaswa pia kufunika extensions za code editors, Python libraries, npm packages na AI tools zinazolenga developers.

Usalama wa software supply chain hauhusu programu kubwa pekee. Wakati mwingine huanza na dependency iliyosakinishwa ndani ya sekunde chache.

3. Zuia mahojiano bandia ya ajira

Shambulio dhidi ya mhandisi wa pili linaonyesha kuwa taratibu za ajira nazo ni sehemu ya attack surface.

Kampuni zinapaswa kuwafundisha wafanyakazi kutambua dalili za mashaka, bila kudhani kuwa mafunzo pekee yanatosha.

Mahojiano ya video yanayoonekana ya kweli hayahakikishi uhalali wa kampuni. Mwajiri anaweza kuwasilisha profiles bandia za kikazi, kutumia majina yaliyoibwa au kutengeneza website inayoshawishi.

Kwa wafanyakazi wenye majukumu nyeti, tests za ajira kutoka nje zinapaswa kufanywa katika mazingira yaliyotengwa.

Mhandisi anaweza kupakua mradi, kuuchunguza na kuuendesha katika virtual machine ya muda, isiyo na siri za kikazi na isiyounganishwa na mifumo ya ndani.

Mazingira hayo yanapaswa kuharibiwa baada ya zoezi.

Hata hivyo, ni lazima kuelewa kuwa virtual machine haitoi ulinzi kamili. Configuration yake, ufikiaji wa mtandao, folders zinazoshirikiwa na vulnerabilities za hypervisor pia lazima vidhibitiwe.

Kanuni ya shirika ingekuwa muhimu sana: zoezi lolote la kiufundi kutoka kwa mwajiri wa nje lichukuliwe kama code isiyoaminika, hata mahojiano yanapoonekana halali.

4. Linda deployment tokens

Huenda hili likawa mojawapo ya hatua muhimu zaidi za kuzuia uvamizi wa IT kugeuka kuwa wizi wa kifedha.

Deployment token haipaswi kamwe kutoa ufikiaji wa resources nyingi kuliko zile zinazohitajika kwa kazi maalumu.

Hii ndiyo kanuni ya least privilege.

Token iliyokusudiwa ku-deploy programu ya ufuatiliaji haipaswi kuruhusu kubadilisha huduma inayosaini transactions.

Ni muhimu pia kupendelea credentials za muda mfupi, zinazozalishwa kwa operesheni maalumu, badala ya secrets za kudumu zilizohifadhiwa kwenye kompyuta za wahandisi.

Hatua zinazopendekezwa ni pamoja na strong authentication, kubadilisha credentials kiotomatiki, centralised secret vaults na kurekodi kwa kina kila matumizi.

Kwa operesheni muhimu, tokens zinapaswa kuhusishwa na service identity inayoweza kuthibitishwa na context maalumu.

Kwa mfano, token iliyoruhusiwa kuchapisha version kutoka kwenye pipeline ya deployment iliyoidhinishwa haipaswi kutumiwa tena kwa uhuru kutoka kwenye kompyuta binafsi ya mhandisi.

Hata token ikiibiwa, huwa haina manufaa makubwa kwa mshambuliaji.

5. Zuia deployments zisizoidhinishwa

Kampuni inayohifadhi cryptocurrency yenye thamani ya mabilioni ya dola haipaswi kuruhusu kompyuta moja iliyoathiriwa kubadilisha tabia ya huduma zake muhimu za kifedha.

Deployments nyeti lazima zipitie mchakato huru wa validation.

Hilo linaweza kujumuisha code review ya lazima, kusaini software artifacts, idhini ya wasimamizi kadhaa na ukaguzi wa kiotomatiki wa mabadiliko kabla ya kuyaweka production.

Pia inawezekana kuzuia kuendeshwa kwa containers ambazo images zake hazitoki kwenye internal registry iliyoidhinishwa.

Admission policy inaweza kuthibitisha kuwa container ina signature halali na inalingana na version iliyoidhinishwa.

Udhibiti huu ni muhimu hasa dhidi ya shambulio linalotumia credentials zilizoibiwa.

Mdukuzi anaweza kufanikiwa kujithibitisha, bila hata hivyo kuweza ku-deploy programu yoyote anayotaka.

6. Tenganisha ruhusa za kusaini na operesheni za IT

Mifumo ya MPC na multisignature lazima iambatane na uthibitishaji huru wa maudhui ya transactions.

Suala si kujua tu kama transaction ina cryptographic signature halali.

Pia ni lazima kuthibitisha kama transaction hiyo imeidhinishwa na kanuni za kifedha za kampuni.

Mfumo imara unapaswa kukagua anwani za walengwa, kiasi, limits za uhamisho, aina za operesheni na mabadiliko ya ruhusa kwenye wallets.

Kwa Ethereum, EIP-7702 authorisations zinahitaji udhibiti maalumu.

Kwa mfano, wallet ya kampuni inaweza kukataza kwa chaguo-msingi delegation yoyote kwa contract isiyoidhinishwa.

Mabadiliko ya signing authorisations yanapaswa kuhitaji validation tofauti na ile inayotumiwa kwa withdrawals za kawaida.

Kwa maneno mengine, huduma inayoweza kuandaa malipo haipaswi pia kuwa na uwezo wa kubadilisha kwa uhuru kanuni zinazoamua nani anayeruhusiwa kuidhinisha malipo hayo.

Huu ni utengano wa msingi.

7. Weka mipaka kwa AI agents

Matumizi yanayodaiwa ya zana ya ndani ya AI katika shambulio la Binance yanafungua eneo jipya la usalama wa mtandao.

Programming assistants za kisasa zinaweza kufikia files, kuuliza code repositories na wakati mwingine kuendesha commands au kutumia huduma za nje.

Uwezo wao huwasaidia developers. Pia unaweza kuongeza madhara ya kompyuta iliyoathiriwa.

Kwa hiyo, shirika linapaswa kuepuka kuwapa AI agents permissions za kudumu na pana.

Agent inapaswa kufikia resources zinazohitajika kwa kazi inayotekelezwa tu.

Utekelezaji wa commands nyeti, ufikiaji wa secrets na deployment operations lazima viwekwe chini ya udhibiti wa ziada.

Idhini ya binadamu inaweza kusaidia, mradi iwe huru kwa kweli na imwezeshe mhusika kuelewa anachokiruhusu.

Maelekezo yaliyo kwenye files za nje, code repositories au documents zinazosomwa na AI yanapaswa pia kuchukuliwa kuwa data isiyoaminika.

Huu ni ulinzi dhidi ya prompt injections zilizoelezwa na OWASP, ambapo maudhui hasidi hujaribu kumsukuma assistant atende kinyume na nia ya mtumiaji. Hii haimaanishi kuwa prompt injection ilithibitishwa katika tukio la Binance; hapa ni pendekezo la jumla la ulinzi.

Hatimaye, vitendo vya agents vinapaswa kurekodiwa na kufuatiliwa. Agent anapoanza kusoma secrets zisizo za kawaida, kuchunguza resources zisizohusiana na kazi yake au kuandaa deployments nyeti, inapaswa kutoa alert.

AI haipaswi kamwe kuwa njia ya kukwepa kanuni za usalama zinazowahusu watumiaji binadamu.

8. Andaa emergency shutdown yenye ufanisi wa kweli

Kisa cha Binance kinaonyesha changamoto nyingine: kusimamisha withdrawals kwenye jukwaa huenda kusitoshe kuondoa authorisations zote zilizokuwapo tayari kwenye blockchain.

Kampuni lazima ziandae taratibu za dharura zinazolingana na kila aina ya wallet.

Kwa Ethereum, hili linajumuisha kujua jinsi ya kugundua na kufuta kwa haraka delegations za EIP-7702 zinazotia shaka, pale configuration ya akaunti inaporuhusu kufutwa huko.

Timu pia zinapaswa kuwa na njia za kutenga huduma zilizoathiriwa, kufuta credentials, kusimamisha deployments na kuzuia kuundwa kwa transactions mpya.

Taratibu hizi hazipaswi kubuniwa wakati wa shambulio.

Mazoezi ya mara kwa mara yanaweza kuiga kuathirika kwa mhandisi, kuibiwa kwa deployment token au kutwaliwa kwa service ya kusaini.

Lengo ni kupima muda ambao shirika linahitaji kugundua, kuelewa na kudhibiti tukio.

Kwa jukwaa linalohamisha mabilioni ya dola, dakika chache zinaweza kuwakilisha hasara kubwa.

9. Gua mashambulio kabla ya uhamisho wa kwanza

Moja ya mambo yanayotia wasiwasi zaidi katika kisa hiki ni muda ambao operesheni hiyo ilitayarishwa.

Kati ya kuathirika kwa kwanza kulikoripotiwa mwezi Juni na wizi wa tarehe 29 Oktoba, miezi kadhaa ilipita.

Kwa hiyo, ufuatiliaji madhubuti haupaswi kuishia kwenye miamala ya kifedha.

Pia unapaswa kutambua mienendo isiyo ya kawaida kwenye kompyuta za wahandisi, majaribio ya kufikia mifumo nyeti na mabadiliko ya ruhusa.

Security logs zinaweza kufichua miunganisho katika saa zisizo za kawaida, deployments zisizotarajiwa au matumizi ya credentials kutoka environments zisizoidhinishwa.

Uchambuzi wa tabia, ikiwezekana ukisaidiwa na AI, unaweza kusaidia kutambua hitilafu hizi.

Hata hivyo, lazima uambatane na taratibu za kibinadamu za uthibitishaji na hatua.

Binance imetangaza kuwa inataka kuimarisha uwezo wake wa detection unaosaidiwa na AI, kufanya kazi na wataalamu huru na kuanzisha mipango mipya ya utafiti wa usalama. Hatua hizi bado ni ahadi zilizotangazwa na kampuni, na ufanisi wake utahitaji kutathminiwa.

10. Watumiaji wa Binance wachukue tahadhari gani?

Wateja wa kawaida hawawezi kuzuia moja kwa moja shambulio dhidi ya miundombinu ya ndani ya jukwaa. Hata hivyo, wanaweza kupunguza hatari yao.

Two-factor authentication, ikiwezekana kwa kutumia physical security key au passkey, bado ni muhimu kulinda akaunti yao wenyewe.

Inapendekezwa pia kutumia password ya kipekee, kuwasha alerts za kuingia na kukagua mara kwa mara vifaa vilivyoidhinishwa.

Kwa kiasi kikubwa kinachokusudiwa kuhifadhiwa kwa muda mrefu, hardware wallet binafsi inaweza kupunguza utegemezi kwa usalama wa jukwaa kuu. Hata hivyo, suluhisho hili linahitaji ulinzi mkali wa recovery phrase na lina hatari zake.

Hatimaye, jihadhari na ujumbe unaodai kuwasaidia waathiriwa wa udukuzi. Baada ya tukio linaloripotiwa sana, huduma bandia za usaidizi, kama katika visa vinavyohusiana na Coinbase, zinaweza kujaribu kuiba credentials au recovery phrases.

Hakuna huduma halali ya usaidizi inayopaswa kumtaka mtumiaji kutoa seed phrase yake.

Ni nini ambacho Binance bado inapaswa kuthibitisha?

Udukuzi wa tarehe 29 Oktoba si suala la malware, AI au ajira bandia pekee. Umefichua hatari za usanifu ambao kuathirika kwa zana kadhaa za development kunaweza hatimaye kuathiri mifumo inayolinda assets za kifedha.

Matumizi ya wahandisi kadhaa, authorisations za kriptografia zilizogawanywa na zana za usalama hayakuzuia operesheni hiyo.

Hilo halifanyi ulinzi huo kuwa hauna maana. Ufanisi wake unategemea uhuru wao kutoka kwa kila mmoja. Ikiwa mifumo kadhaa ya usalama inaweza kutawaliwa kupitia mnyororo mmoja wa uvamizi, kuikusanya pamoja hakuhakikishi utengano wa kweli wa hatari.

Kipaumbele cha Binance sasa ni kuweka wazi kwa usahihi permissions zilizotumiwa vibaya, components zilizoathiriwa, mifumo ya kusaini iliyotumiwa na controls ambazo hazikufanya kazi kama ilivyotarajiwa.

Jukwaa linasema limerejesha kwa kiwango kikubwa assets zilizoathiriwa. Hilo ni jibu muhimu la kifedha kwa watumiaji. Hata hivyo, peke yake si ushahidi kuwa vulnerabilities zilizosababisha shambulio zimeondolewa.

Hakuna kampuni inayoweza kuhakikisha haitawahi kuvamiwa tena. Lakini inaweza kubuni mifumo yake kiasi kwamba kompyuta iliyoambukizwa, mahojiano bandia ya ajira au token iliyoibiwa visitoshe kuhatarisha mabilioni ya dola.

Ni uwezo huo wa kudhibiti madhara, zaidi ya ahadi za kurejesha fedha, ambao usalama wa baadaye wa Binance utapaswa kupimwa nao.

Ukweli kuhusu uvamizi unategemea hasa kauli za Binance zilizoripotiwa wakati wa briefing yake na uchambuzi uliotajwa. Mapendekezo haya ni uchambuzi wa ulinzi; utekelezaji wake halisi na Binance haujakaguliwa na BrefCrypto.