Phân tích lỗ hổng Stride Airdrop

Các nhà phát triển xây dựng dựa trên IBC và các kỹ sư bảo mật đang xem xét tích hợp IBC nên xem xét cẩn thận bề mặt tấn công tiếp xúc với các máy khách hoặc kênh IBC độc hại.

Được viết bởi: Sẽ

Lời nói đầu: Bài viết này mô tả một lỗ hổng mà Jump Crypto đã phát hiện ra trong chương trình airdrop Stride: Stride là một chuỗi Cosmos được sử dụng để đặt cược thanh khoản trong hệ sinh thái Cosmos. Sự cố này có thể cho phép kẻ tấn công đánh cắp tất cả các đợt airdrop không có người nhận trên Stride. Tại thời điểm phát hiện ra, hơn 1,6 triệu STRD (tương đương khoảng 4 triệu USD) đang gặp rủi ro. Jump đã báo cáo riêng về lỗ hổng này cho những người đóng góp cho Stride và sự cố đã được khắc phục kể từ đó, không có hoạt động khai thác độc hại nào xảy ra do những nỗ lực của chúng tôi. Địa chỉ liên kết gốc [1]

Airdrop trên Stride

Stride thường xuyên tiến hành các đợt airdrop lớn của mã thông báo gốc [$STRD] để khuyến khích hoạt động của mạng và phân quyền quản trị giữa một nhóm rộng lớn các bên. Mã để phân bổ và yêu cầu airdrop có tại x/claim [2] thực hiện trong mô-đun. Phân bổ airdrop thông qua LoadAllocationData [3] được xác định bởi một chức năng tải tệp phân bổ chứa địa chỉ và phân bổ airdrop. Đối với hầu hết các đợt airdrop, các địa chỉ được tải mô tả người dùng trên các chuỗi Cosmos khác, chẳng hạn như Osmosis hoặc Juno, vì vậy, trước tiên, mã sẽ chuyển đổi chúng thành địa chỉ Stride bằng cách sử dụng hàm utils.ConvertAddressToStrideAddress.

Đối với mỗi tài khoản trong đợt airdrop, mô-đun sẽ tạo một Bản ghi Yêu cầu [4] , chứa số nhận dạng airdrop cho một đợt airdrop cụ thể, địa chỉ đã chuyển đổi và số lượng mã thông báo được phân bổ cho người dùng. Sau khi tạo ClaimRecord, người dùng có địa chỉ Stride tương ứng có thể gửi MsgClaimFreeAmount tới chuỗi [5] Hãy đến và yêu cầu airdrop của họ.

Tuy nhiên, việc triển khai này không hoạt động trong đợt airdrop EVMOS gần đây vì hàm utils.ConvertAddressToStrideAddress ánh xạ địa chỉ Evmos sang địa chỉ Stride không thể truy cập được. Điều này là do các địa chỉ EVMOS được lấy bằng loại tiền 60, trong khi địa chỉ Stride được lấy bằng loại tiền 118.

Để những người dùng bị ảnh hưởng vẫn có thể yêu cầu airdrop, nhóm đã thêm khả năng cập nhật địa chỉ mục tiêu của một Bản ghi Yêu cầu chưa được xác nhận thông qua tin nhắn IBC chuỗi chéo từ tài khoản EVMOS tương ứng. Cơ chế cập nhật này được triển khai như một phần của mô-đun x/autopilot. x/lái tự động [6] Chặn một đường truyền IBC ICS-20 đang đến và cố gắng trích xuất các hướng dẫn dành riêng cho Stride từ trường ghi nhớ hoặc bộ thu của nó (trường bộ thu tăng gấp đôi dưới dạng trường ghi nhớ trong các phiên bản IBC trước v5):

func(imIBCModule)OnRecvPacket(

ctxsdk.Context,

packetchanneltypes.Packet,

relayersdk.AccAddress,

)ibcexported.Xác nhận{

// LƯU Ý: xác nhận sẽ được viết đồng bộ trong quá trình xử lý IBCandlerution.

datatransfertypes.FungibleTokenPacketData

iferr:=transfertypes.ModuleCdc.UnmarshalJSON(packet.GetData(),&data);err!=nil{

returnchanneltypes.NewErrorAcknowledgement(err)

}

[..]

//ibc-gov5hasaMemofieldthatcanstoreforwardinginfo

//Forolderversionofibc-go,thedatamustbestoredinthereceiverfield

chuỗi siêu dữ liệu

ifdata.Memo!=""{//ibc-gov5+

siêu dữ liệu=data.Memo

}else{//b Beforeibc-gov5

siêu dữ liệu=data.Receiver

}

[..]

//parseoutanyforwardinginfo

packetForwardMetadata,err:=types.ParsePacketMetadata(siêu dữ liệu)

iferr!=nil{

returnchanneltypes.NewErrorAcknowledgement(err)

}

// Iftheparsedmetdatataisnil,thatnghĩalàkhôngcóchuyểntiếplogic

//Passthepacketdowntothenextmiddleware

ifpacketForwardMetadata==nil{

returnim.app.OnRecvPacket(ctx,packet,relayer)

}

// Sửa đổi dữ liệu gói bằng cách thay thế trường siêu dữ liệu JSON bằng địa chỉ nhận

// toallowthepacketto continuedownthestack

dữ liệu mới:=dữ liệu

newData.Receiver=packetForwardMetadata.Receiver

bz,err:=transfertypes.ModuleCdc.MarshalJSON(&newData)

iferr!=nil{

returnchanneltypes.NewErrorAcknowledgement(err)

}

gói mới := gói

newPacket.Data=bz

//Passthenewpacketdownthemiddlewarestackfirst

ack:=im.app.OnRecvPacket(ctx,newPacket,relayer)

if!ack.Success(){

hồi hương

}

autopilotParams:=im.keeper.GetParams(ctx)

// Nếu quá trình truyền thành công, thì định tuyến đến mô-đun tương ứng, nếu có

switchroutingInfo:=packetForwardMetadata.RoutingInfo.(type){

casetypes.StakeibcPacketMetadata:

[…]

casetypes.ClaimPacketMetadata:

// Ifclaimroutingisinactive(butthepackethadroutinginfointhememo)returnanackerror

[..]

im.keeper.Logger(ctx).Info(fmt.Sprintf("Forwaringpacketfrom%stoclaim",newData.Sender))

iferr:=im.keeper.TryUpdateAirdropClaim(ctx,newData,routingInfo);err!=nil{

im.keeper.Logger(ctx).Error(fmt.Sprintf("Errorupdatingairdropclaim fromautopilotfor%s:%s",newData.Sender,err.Error()))

returnchanneltypes.NewErrorAcknowledgement(err)

}

hồi hương

mặc định:

returnchanneltypes.NewErrorAcknowledgement(errorsmod.Wrapf(types.ErrUnsupportedAutopilotRoute,"%T",routingInfo))

}

}

Nếu siêu dữ liệu đi kèm chỉ ra rằng chuyển tiền đến là yêu cầu airdrop, mô-đun sẽ gọi hàm TryUpdateAirdropClaim:

func(kKeeper)TryUpdateAirdropClaim(

ctxsdk.Context,

datatransfertypes.FungibleTokenPacketData,

packetMetadatatypes.ClaimPacketMetadata,

)lỗi{

[..]

// lấy các địa chỉ liên quan

senderStrideAddress:=utils.ConvertAddressToStrideAddress(data.Sender)

ifsenderStrideAddress==""{

returnerrorsmod.Wrapf(sdkerrors.ErrInvalidAddress,fmt.Sprintf("địa chỉ người gửi không hợp lệ(%s)",data.Sender))

}

newStrideAddress:=packetMetadata.StrideAddress

//cập nhậttheairdrop

airdropId:=packetMetadata.AirdropId

k.Logger(ctx).Info(fmt.Sprintf("updatingairdroppaddress%s(orig%s)to%sforairdrop%s",

senderStrideAddress,data.Sender,newStrideAddress,airdropId))

returnk.claimKeeper.UpdateAirdropAddress(ctx,senderStrideAddress,newStrideAddress,airdropId)

}

Hàm chuyển đổi địa chỉ của gói IBC của người gửi thành địa chỉ Stride có tên senderStrideAddress, đồng thời trích xuất airdropId và địa chỉ airdrop mới newStrideAddress từ siêu dữ liệu của gói. Sau đó, nó gọi UpdateAirdropAddress để cập nhật một ClaimRecord đang mở khớp với sự kết hợp của senderStrideAddress và airdropId với địa chỉ mới.

Với bản cập nhật của ClaimRecord, newStrideAddress hiện có thể yêu cầu airdrop. Điều quan trọng cần lưu ý là cơ chế cập nhật này chỉ được bảo vệ bởi địa chỉ người gửi được chỉ định trong gói IBC. Stride không thực hiện bất kỳ xác minh nào khác để đảm bảo rằng các bản cập nhật cho airdrop được kích hoạt bởi người nhận thực.

Để hiểu tại sao đây là một lỗ hổng nghiêm trọng, chúng ta cần xem xét kỹ hơn về IBC, giao thức liên lạc giữa các chuỗi khối.

Bảo mật IBC

IBC là một cơ chế giao tiếp xuyên chuỗi dựa trên máy khách nhẹ. Tương tự như các giao thức mạng cổ điển, mô-đun IBC lõi trừu tượng hóa nhiều chi tiết cấp thấp, cho phép các nhà phát triển dễ dàng xây dựng các tích hợp của riêng họ trên mô-đun đó. Việc kết nối một chuỗi hỗ trợ IBC (Chuỗi A) với một chuỗi hỗ trợ IBC khác (Chuỗi B) trông giống như sau:

CreatedsolomachineclientonIBCenabledchain[ClientID=06-solomachine-6]

Đã tạotendermintclientonsolomachine[ClientID=07-tendermint-M48f]

Chuỗi kết nối được khởi tạo trên IBCenabled[ConnectionID=connection-4]

Khởi tạo kết nốionsolomachine[ConnectionID=connection-Kinb]

Đã xác nhận kết nối trên IBCenabledchain[ConnectionID=connection-4]

Đã xác nhận kết nốionsolomachine[ConnectionID=connection-Kinb]

Đã khởi tạochannelonIBCenabledchain[ChannelID=channel-0]

Đã khởi tạo kênhonsolomachine[ChannelID=channel-wwl6]

Kênh đã xác nhận trên IBCenabledchain[ChannelID=channel-0]

Đã xác nhận kênhonsolomachine[ChannelID=channel-wwl6]

Kết nối thành lập!

Trong bước đầu tiên, một ứng dụng khách nhẹ IBC của chuỗi A được tạo trên chuỗi B và ngược lại. Ứng dụng khách IBC được xác định duy nhất bằng ID ứng dụng khách của nó, được sử dụng để theo dõi và xác minh trạng thái của chuỗi từ xa. Sau khi khách hàng được tạo, họ có thể kết nối thông qua kết nối, được bắt đầu bằng bắt tay bốn bước. Điều này tạo ra một ConnectionEnd trên chuỗi A với các ứng dụng nhẹ của chuỗi B trên A và một kết nối khác trên chuỗi B với các ứng dụng khách nhẹ của chuỗi A trên B. Các kết nối, sau khi được tạo, sẽ được duy trì và mã hóa bởi hai ứng dụng khách nhẹ.

Giao tiếp qua các kết nối cũng được chia thành các kênh khác nhau. Các kênh được xác định bởi kết nối cơ bản và các cổng nguồn và đích. Mỗi cổng xác định một mô-đun trên chuỗi tương ứng được kết nối thông qua IBC. ChannelEnd được liên kết với Kết nối được tạo trên cả hai chuỗi và được xác định theo id kênh. Dữ liệu hiện có thể được truyền giữa hai chuỗi thông qua kênh đã thiết lập.

Điều quan trọng cần nhớ là IBC là một giao thức không được phép theo mặc định. Điều này có nghĩa là bất kỳ ai cũng có thể kết nối bất kỳ hai chuỗi hỗ trợ IBC nào mà không cần sự cho phép hoặc phê duyệt trước. Trên thực tế, IBC hỗ trợ cái gọi là Máy Solo [7] Theo tiêu chuẩn, một máy khách không đại diện cho một chuỗi khối mà là một máy chủ hoặc máy đơn lẻ. Vì nội dung gói IBC được kiểm soát hoàn toàn bởi người gửi (thường là mô-đun nguồn trên chuỗi nguồn), nên các mô-đun thực hiện các hoạt động đặc quyền trên các gói IBC đến luôn cần xác minh rằng thông báo đến từ một kênh đáng tin cậy.

Lỗ hổng

Tuy nhiên, đối với Stride, tính năng kiểm tra kênh bị thiếu trong mô-đun x/autopilot. Mã giả định rằng các gói ICS-20 IBC có địa chỉ người gửi cụ thể chỉ có thể được gửi bởi người có quyền kiểm soát địa chỉ đó. Điều này đúng nếu chúng ta chỉ xem xét các mô-đun vận chuyển trên các chuỗi đối tác đáng tin cậy như EVMOS, nhưng những kẻ tấn công có thể chỉ cần gửi dữ liệu gói IBC được kiểm soát hoàn toàn để sử dụng các ứng dụng khách IBC độc hại dưới sự kiểm soát của chúng. Việc khai thác lỗ hổng này tương đối đơn giản:

1. Tạo ứng dụng khách IBC độc hại
2. Sử dụng ứng dụng độc hại Craft để tạo kênh IBC cho mô-đun vận chuyển Stride IBC,
3. Và gửi chuyển khoản IBC độc hại bằng cách sử dụng địa chỉ của các Bản ghi Yêu cầu không được xác nhận dưới dạng trường Từ. Sử dụng trường ghi nhớ ClaimMetadata để kích hoạt chế độ lái tự động và cập nhật địa chỉ airdrop thành tài khoản Stride do kẻ tấn công kiểm soát.
4. Đánh cắp airdrop bằng cách gửi MsgClaimFreeAmount tới mô-đun x/claim

Sửa lỗi

Khi nhận được báo cáo nhanh chóng của chúng tôi, người đóng góp cho Stride đã nhanh chóng rút tất cả tiền từ ví của người bán lại Airdrop để đảm bảo không có khoản tiền nào gặp rủi ro. Đã triển khai bản sửa lỗi dài hạn để đảm bảo rằng các gói cập nhật địa chỉ airdrop IBC đến qua đúng kênh IBC đáng tin cậy.

Tóm lại là

Hỗ trợ mạnh mẽ cho giao tiếp xuyên chuỗi thông qua IBC là một lợi thế độc đáo của hệ sinh thái Cosmos. Mặc dù IBC được xây dựng trên các nguyên tắc mật mã vững chắc, nhưng việc tích hợp an toàn với nó đòi hỏi phải hiểu rõ về mô hình tin cậy cơ bản. Các nhà phát triển xây dựng dựa trên IBC và các kỹ sư bảo mật xem xét tích hợp IBC nên xem xét cẩn thận bề mặt tấn công tiếp xúc với các máy khách hoặc kênh IBC độc hại. Chúng tôi xin cảm ơn những người đóng góp cho Stride vì cách xử lý chuyên nghiệp và phản hồi nhanh chóng của họ đối với vấn đề này.

Liên kết ngoài WeChat

[1] Địa chỉ liên kết gốc:

[2] x/yêu cầu:

[3] LoadAllocationData:

[4] Hồ sơ yêu cầu:

[5] MsgClaimFreeAmount:

[6] x/lái tự động:

[7] Máy độc tấu: