USPD đã bị tấn công mạng bằng một kỹ thuật được mô tả là bí mật hoặc âm thầm . Nhóm điều tra tuyên bố vụ tấn công không hiển thị trên Etherscan và kẻ tấn công có quyền truy cập ẩn . Tất cả những điều đó đều là sự mô tả sai lệch, và có thể là lời nói dối, như chúng ta sẽ chứng minh ngay bây giờ. Hoặc có thể chỉ là một cách nhìn quá đơn giản về toàn bộ vấn đề này.
Một nhóm có năng lực và không cẩu thả lẽ ra đã có thể, và sẽ, phát hiện ra vấn đề ngay lập tức vào tháng 9 khi giao thức bị xâm phạm. Và bất kỳ "nhà nghiên cứu" bảo mật nào ủng hộ quan điểm rằng điều này đã bị "che giấu" cũng đều thiếu năng lực, cẩu thả và không đáng tin cậy.
Chỉ sử dụng các công cụ miễn phí có sẵn công khai như Etherscan, nhóm đã có thể phát hiện ra vấn đề ngay tại thời điểm triển khai. Một nhóm có năng lực và siêng năng chắc chắn sẽ nhận ra điều này. Không cần đến công cụ đặc biệt nào. Đúng là Etherscan đôi khi che giấu một số thông tin quan trọng. Chúng tôi đã từng khẳng định rằng việc tin tưởng mù quáng vào Etherscan để biết điều gì đang xảy ra là một ý tưởng tồi. Chúng tôi cũng đã từng khẳng định rằng, theo quan điểm của chúng tôi, các nhóm đang lợi dụng những thiếu sót của Etherscan để che giấu mức độ kiểm soát mà họ thực sự có đối với sản phẩm của mình. Có lẽ quan điểm của chúng tôi thậm chí nên thấp hơn nữa: điều gì sẽ xảy ra nếu các nhóm này không nhận ra rằng họ có quyền kiểm soát vì điều đó không hiển thị trên Etherscan? Điều đó sẽ rất rắc rối, ngu ngốc và đáng buồn.
Nhưng USPD không phức tạp đến thế. Rõ ràng đây là sự kết hợp giữa sơ suất và thiếu năng lực vì thông tin liên quan đã không bị che giấu. Đúng là chúng ta nên kỳ vọng các nhà phát triển sử dụng mọi công cụ cần thiết để đảm bảo hệ thống của họ được triển khai đúng cách. Nhưng có sự khác biệt giữa việc không sử dụng phần mềm chuyên dụng, hoặc không tự xây dựng các công cụ giám sát phức tạp, và những gì đã xảy ra ở đây. Nhóm này đã không sử dụng phần mềm tiêu chuẩn, có sẵn miễn phí và sau đó nói dối rằng các vấn đề không thể phát hiện được bằng phần mềm đó.
Giờ đây, chúng ta sẽ chứng minh đây là trường hợp thiếu hiểu biết và sai sót chứ không phải là một cuộc tấn công bí mật phức tạp mà một nhóm có năng lực có thể đã bỏ sót. Đúng vậy, nhóm đã bỏ sót vấn đề này. Chúng ta không phủ nhận điều đó. Mục đích của chúng ta ở đây là vạch trần sự thiếu năng lực và cẩu thả của nhóm. Chúng ta sẽ làm điều đó bằng cách chỉ ra những tín hiệu cảnh báo rõ ràng có thể nhìn thấy ngay khi vấn đề xảy ra mà nhóm đã bỏ qua.
Chi tiết
Chúng ta có thể thấy trên GitHub của dự án rằng một trong những hợp đồng mà họ biết đã triển khai là "bộ ổn định" tại địa chỉ 0x1346B4d6867a382B02b19A8D131D9b96b18585f2. Chúng ta có thể sử dụng Etherscan để xem giao dịch triển khai bằng các công cụ tiêu chuẩn. Theo Etherscan, giao dịch này được thực hiện vào lúc 13:01:59 UTC ngày 16 tháng 9 năm 2025.
Và sau đó chúng ta có thể thấy 6 nhật ký từ cùng địa chỉ 0x1346 này vào lúc 13:02:11 ngày 16 tháng 9 năm 2025 (UTC), 1 Block sau đó. Nhật ký có thể được xem dễ dàng bằng nhiều công cụ miễn phí tiêu chuẩn. 6 nhật ký đó là:
- Một vai trò được cấp cho một hợp đồng mã nguồn đóng, có lẽ từ kẻ tấn công tại: 0xc2a0aD4Bd62676692F9dcA88b750BeC98E526c42.
- Một vai trò khác được cấp cho cùng một hợp đồng mã nguồn đóng.
- InsuranceEscrowUpdated , cập nhật hợp đồng ký quỹ bảo hiểm, thành cùng một hợp đồng nguồn đóng.
- Đã khởi tạo , cho biết giao thức đã được khởi tạo.
- Thông báo "Đã nâng cấp" cho thấy một dạng nâng cấp proxy nào đó lên 0xAC075b9bf166e5154Cc98F62EE7b94E5345Cc090, một hợp đồng mã nguồn đóng khác.
- Lần này đã được nâng cấp lên hợp đồng thực thi chính thức của USPD.
Nếu nhóm chỉ cần xem xét các sự kiện trên hợp đồng của họ sau khi triển khai, họ sẽ thấy những sự kiện này. Điều này có thể được thực hiện trên Etherscan. Hoặc trên nhiều nền tảng khác, cả miễn phí và không miễn phí.
Hai hợp đồng mã nguồn đóng được đề cập rất đáng ngờ và lẽ ra đã cho nhóm biết ngay rằng có điều gì đó không ổn. Bất kỳ nhóm nào có năng lực cũng sẽ nhận thấy những hợp đồng bất ngờ và đặt câu hỏi chuyện gì đã xảy ra.
Làm sao chúng ta biết đó không phải là những hợp đồng mà nhóm dự định? Bởi vì các địa chỉ bị lộ trong các sự kiện đó hiện đã được gắn cờ là của kẻ tấn công. Chúng ta sẽ đi vào một vài chi tiết ngay bây giờ, nhưng thực sự, một khi nhóm phát hiện ra các địa chỉ không mong muốn có quyền quản trị và các thứ được liên kết với proxy… đó là một dấu hiệu cảnh báo đỏ rõ ràng nhất có thể. Nhóm không ngờ hai địa chỉ đó lại xuất hiện ở bất cứ đâu, vì vậy hoặc a) họ đã thấy các nhật ký này và bỏ qua chúng hoặc b) họ chưa bao giờ thấy các nhật ký đó. Cả hai khả năng đều là lỗi của nhóm.
Nhật ký RoleGranted liên quan đến quyền hạn trong giao thức và một lần nữa, đây là một dấu hiệu cảnh báo rõ ràng cho thấy quyền hạn đã được cấp cho các hợp đồng bên ngoài một cách ngẫu nhiên.
Như đã nói ở trên, các nhà nghiên cứu bảo mật hiện liệt kê hai địa chỉ trên là độc hại. Đối với bên ngoài, không thể biết chắc chắn liệu chúng có phải là một phần của cuộc tấn công mạng nào đó hay không. Có thể đó chỉ là những sai sót. Có lẽ nhóm đã triển khai các liên hệ đó một cách nhầm lẫn và không bận tâm đến việc công khai nguồn gốc vì đó là những lỗi sẽ không bao giờ được sử dụng trong môi trường sản xuất. Chúng ta thường xuyên tìm thấy các bản nâng cấp tạm thời cho các hợp đồng mã nguồn đóng ngẫu nhiên trên các giao thức mã nguồn mở. Thường thì không ai bận tâm đến việc xác minh các triển khai lỗi tạm thời này. Đôi khi các giao thức chỉ đơn giản là nói dối về việc chúng có phải là mã nguồn mở hay không. Rõ ràng đó là một vấn đề, nhưng đó là một vấn đề khác.
Nhưng nhóm USPD hẳn đã biết đây là những vấn đề bảo mật. Nhóm đó biết mình đã triển khai những hợp đồng nào. Nhóm đó biết những địa chỉ này không nằm dưới sự kiểm soát của họ. Đối với một bên ngoài, vào thời điểm đó không thể nhận ra điều gì đó bất thường. Nhưng đối với một nhóm có năng lực: đúng vậy, điều đó hoàn toàn có thể xảy ra chỉ bằng những công cụ đơn giản, miễn phí và tiêu chuẩn. Một bên ngoài hoàn toàn có thể phát hiện ra điều bất thường và đặt câu hỏi. Và kết quả buồn cười nhất ở đây có lẽ là một nhà nghiên cứu bảo mật nào đó hỏi USPD vào thời điểm đó và bị từ chối hoặc phớt lờ. Nhưng tiếc thay, điều đó dường như đã không xảy ra. Nếu bạn biết điều này đã xảy ra, hãy liên hệ với chúng tôi.
Những việc mà đội đã làm
Chúng ta có thể thấy nhóm đã ghi lại địa chỉ triển khai 0x1346 trên GitHub vài giờ sau các sự kiện trên. Chúng ta có thể thấy một nhà phát triển đã dành vài giờ cho việc này và cần nhiều lần commit để cập nhật đầy đủ mọi thứ. Điều buồn cười là chính nhà phát triển đó đang làm việc với các bài kiểm tra vào thời điểm đó . Họ thậm chí còn commit một Script vào ngày 18 tháng 9 để "triển khai lại USPDToken với cách triển khai và quyền hạn mới", vì vậy bạn có thể tự hỏi liệu tomw1808 có biết có vấn đề gì không? Chúng ta không biết liệu người đó có chịu trách nhiệm xác minh việc triển khai on-chain hay không, nhưng đó sẽ là một điểm khởi đầu tốt để đặt câu hỏi. Có lẽ có một mạch truyện hài hước chưa được khai thác nào đó đang chờ đợi ở đây.
Cuối cùng, cần lưu ý rằng cả hai cuộc kiểm toán dự án đều được thực hiện trước khi triển khai, vì vậy họ không thể phát hiện ra bất cứ điều gì liên quan đến việc triển khai vì việc triển khai chưa diễn ra. Và dường như không ai kiểm toán việc triển khai. Hoặc, nếu có ai đó đã làm, thì đó không phải là một cuộc kiểm toán có năng lực — hoặc có lẽ không được đón nhận một cách có năng lực.
Tóm lại: vấn đề không nằm ở mã nguồn mà là cách triển khai nó. Nhưng điều đó không có nghĩa là mã nguồn đó đặc biệt tốt! Dưới đây là một đoạn trích từ mục lục của một báo cáo kiểm toán:
Bạn không cần phải là một lập trình viên chuyên nghiệp để nhận ra rằng những lời nhận xét đó chỉ nhằm ám chỉ "đây là mã nguồn tồi tệ, nghiệp dư và lỗi thời". Cả hai cuộc kiểm toán đều phát hiện ra các vấn đề trong quá trình khởi tạo và cả hai đều tuyên bố, ở một mức độ nào đó, đã xem xét quá trình triển khai. Vì vậy, đúng là các kiểm toán viên nên bị đánh giá thấp một phần vì đã không xác định rõ hơn quy trình triển khai và khởi tạo kém hiệu quả. Nhưng nhóm phát triển chắc chắn phải chịu trách nhiệm lớn nhất ở đây. Một lần nữa: nếu bất kỳ ai tham gia vào quá trình kiểm toán biết thêm thông tin nào khác, vui lòng cho chúng tôi biết. Chúng tôi sẵn sàng xem xét khả năng vấn đề này đã được thảo luận, bỏ qua và giải quyết bằng thương lượng.
Giờ thì bạn có thể cho rằng việc triển khai nằm ngoài phạm vi nếu muốn. Nhưng những vấn đề như “mã nguồn dư thừa trong toàn bộ giao thức” đối với một hệ thống mà mã nguồn không thể nâng cấp, và “rủi ro tập trung hóa trên cUSPD” khi đó là một phần của thiết kế… thì đó không phải là những vấn đề nghiêm trọng. Những cuộc kiểm toán này, nói một cách nhẹ nhàng nhất, chỉ được tô điểm bằng những nội dung không có giá trị. Chúng ta không biết liệu điều đó cũng đã được thương lượng và có thể đã bị che giấu bằng một số nội dung giải trí khác hay không.
Đây có phải là một vụ hack không?
Trong trường hợp này, "kẻ tấn công" đã thực hiện một phần quá trình triển khai bằng cách chạy trước mã của chính họ để chiếm ưu thế trong giao dịch của nhóm nhằm trục lợi. Ở đây, chúng ta sử dụng thuật ngữ "chạy trước" theo nghĩa kỹ thuật và không có ý định bày tỏ bất kỳ quan điểm nào về tính hợp pháp hay đạo đức.
Điều này nghe rất giống vụ Peraire-Bueno, nơi những kẻ được cho là "hacker" đã lấy tiền của ai đó thông qua quy trình xây dựng khối cạnh tranh nằm ở cốt lõi của Ethereum. Trong vụ USDP và vụ Peraire-Bueno, không ai hack khóa riêng tư của ai cả. Không ai đột nhập vào nhà hoặc văn phòng của ai cả. Không ai tham gia vào cuộc tấn công lừa đảo hoặc nói dối. Mọi thứ đều nằm trong phạm vi của giao thức Ethereum.
Trong cả hai trường hợp, chúng ta đều có một hình thức giao dịch trước. Trong trường hợp USDP, nó giống như việc ai đó để cửa trước mở và để chìa khóa xe trên bàn. Ngoại trừ các giao dịch trên Ethereum tồn tại trong một môi trường mà việc lấy chiếc xe đó không bị coi là trộm cắp.
Không có sự khác biệt nào giữa việc sử dụng cơ chế chuyển tiếp-xây dựng khối-bộ nhớ-đồng thuận phức tạp để đi trước giao dịch trên Sàn phi tập trung (DEX) và việc đi trước một triển khai như thế này. Cả hai đều "khai thác" cùng một tính năng giao thức mà cộng đồng Ethereum muốn xây dựng và muốn sử dụng.
Bản kiến nghị ủng hộ anh em nhà Peraire-Bueno của Coin Center lập luận rằng hành vi giao dịch nội bộ (front-running) của họ là hoàn toàn công bằng, hợp lý và hợp pháp trên Ethereum, viết như sau:
Ethereum là một công nghệ và hệ sinh thái toàn cầu. Nó còn mới mẻ, thay đổi nhanh chóng và Chưa được kiểm soát, ngoại trừ các động lực kinh tế nội bộ, các biện pháp kiểm soát mật mã và sự cạnh tranh khốc liệt giữa các bên xác thực – bao gồm cả các bị cáo và các nạn nhân được cho là – như mô tả bên dưới. Phần mềm mã nguồn mở của Ethereum thiết lập các quy tắc và kiểm soát cho cuộc cạnh tranh đó nhờ vào sự đóng góp phần mềm tự nguyện của hàng ngàn nhà phát triển cá nhân xuất sắc, làm việc minh bạch và hợp tác. Thật khó tin khi phán quyết của một số ít công tố viên có thể dẫn đến việc áp đặt các tiêu chuẩn kỹ thuật thay thế cụ thể cho những gì được coi là tham gia hợp pháp vào công nghệ đó, và những tiêu chuẩn đó lại mâu thuẫn rõ ràng với nhiều quy tắc đã được thiết lập trong phần mềm mã nguồn mở đó, nói một cách ngắn gọn, là điều cực đoan.
Vậy là toàn bộ vấn đề này được xây dựng dựa trên “sự cạnh tranh khốc liệt” trong khuôn khổ “các quy tắc rõ ràng” đã được thiết lập. Và bất kỳ ai hoạt động trong khuôn khổ các quy tắc đó đều không vi phạm pháp luật vì tất cả những người tham gia đều tự nguyện lựa chọn hình thức sắp xếp này. Đó là lập luận được đưa ra. Coin Center tiếp tục:
Trên thực tế, các nạn nhân được cho là người dùng của các phần mềm Bots cực kỳ thành công, những phần mềm này tìm cách tham gia vào cuộc cạnh tranh khốc liệt để tối đa hóa giá trị có thể khai thác được đến giới hạn cực đoan của giao thức, giống như những người tham gia trong ngành mong đợi và nên mong đợi. Thiệt hại được cho là đơn giản chỉ là họ đã bị các bị cáo cạnh tranh vượt mặt, những người cũng tìm kiếm nhiều con đường thương mại và kỹ thuật khác nhau để tối đa hóa phần thưởng Block của riêng họ đến giới hạn được xác định bởi các quy tắc Consensus hẹp của giao thức dành cho sự tham gia "trung thực".
Họ tiếp tục lập luận rằng tất cả điều này đều tốt vì các quy tắc đơn giản, rõ ràng là cách duy nhất để đạt được kết quả tối ưu và, một lần nữa, tất cả những người liên quan đều lựa chọn tham gia trên các điều khoản này:
Trong giới tư tưởng về tiền điện tử, mục tiêu khiến Thợ đào hoặc người xác thực cạnh tranh dưới những ràng buộc tối thiểu và rõ ràng, cùng với các hình phạt tự động cho việc không tuân thủ, không phải là định kiến cố hữu đối với thị trường hay cho rằng lòng tham là tốt theo nghĩa của Gordon Gecko. Thay vào đó, đó là sự thừa nhận rằng lợi ích cá nhân sẽ luôn tồn tại và các quy tắc cạnh tranh đơn giản hơn, không chịu ảnh hưởng bởi thông tin hoặc áp lực bên ngoài không thể kiểm chứng (như bên ngoài việc xác minh toán học của blockchain), sẽ đảm bảo tốt hơn rằng lợi ích cá nhân đó được kiềm chế cho một mục đích đơn giản và trung lập về chính trị: chỉ đơn thuần là xác thực giao dịch toán học.
Vụ "tấn công" của USPD không vi phạm bất kỳ quy tắc Consensus của Ethereum. Không ai đánh cắp bất cứ thứ gì. Đó chỉ đơn thuần là trường hợp một người tham gia ngành công nghiệp khéo léo đã "cạnh tranh vượt trội" so với một nhóm được thừa nhận là thiếu năng lực. Nếu bạn muốn lập luận rằng nhóm này thiếu năng lực cần thiết để tham gia vào đấu trường cạnh tranh của Ethereum, thì bạn cần giải thích quy trình phê duyệt tham gia hoạt động như thế nào. Bảo vệ những người yếu thế và thiếu hiểu biết có thể là một mục tiêu cao cả. Nhưng cần có một quy trình nào đó để xác định ai được coi là yếu thế và thiếu hiểu biết, và ai được phép tham gia vào cuộc chơi dành cho người lớn. Gọi đây là một vụ hack tức là lập luận rằng việc tham gia vào quy trình Consensus của Ethereum cần phải vượt qua một bài kiểm tra năng lực vượt xa khả năng chỉ đơn thuần vận hành phần mềm. Hừm.
Điều này đặt chúng ta vào một tình thế thú vị. Phần lớn ngành công nghiệp web3 chia sẻ quan điểm của Coin Center về vụ Peraire-Bueno. Nếu đó là một quan điểm được giữ vững một cách trung thực, thì các bên đó cũng phải đồng ý rằng đây không phải là một vụ tấn công mạng. Hơn nữa, ngành công nghiệp cần phải nhận ra rằng nhóm và quy trình này đã có những thiếu sót nghiêm trọng.
Việc không thừa nhận "lỗi hack" này là hành vi hoàn toàn chấp nhận được sẽ cho thấy rõ lập trường của ngành công nghiệp này không nhất quán, trừ khi chúng phục vụ lợi ích riêng của họ. Chúng ta không mong đợi sự nhất quán về mặt tư duy từ nhóm vận động hành lang web3 và chúng ta sẽ không ngạc nhiên khi họ từ chối tham gia vào một vụ việc như thế này, vốn phơi bày sự đạo đức giả của họ. Nhưng việc đặt câu hỏi vẫn đáng giá.
Cuối cùng: việc không có biện pháp trừng phạt xã hội nào đối với những nhà phát triển thiếu năng lực này sẽ chỉ đảm bảo rằng điều này xảy ra thường xuyên hơn trong tương lai vì nó chỉ dựa vào những tính năng của Ethereum mà cộng đồng muốn sử dụng và không muốn loại bỏ. Nhóm phát triển lẽ ra phải phát hiện ra vấn đề ngay lập tức và sửa chữa quy trình triển khai trước khi ra mắt. Nếu bạn chấp nhận hệ sinh thái Ethereum như hiện tại, USPD đang gặp vấn đề về xã hội chứ không phải vấn đề kỹ thuật. Và điều đó có nghĩa là "giải pháp" cũng mang tính xã hội.
Bài viết "USPD Hack: Details & Questions" ban đầu được đăng trên ChainArgos trên Trung bình, nơi mọi người đang tiếp tục cuộc thảo luận bằng cách nêu bật và phản hồi về câu chuyện này.
