Author: manthang

A man is interested in building large-scale, high performance systems and breaking stuffs.

“Khẩu thần công” trên Internet của China


Citizen Lab vừa công bố một báo cáo về một công cụ tấn công trên Internet mới có nguồn gốc từ China và được sử dụng trong đợt tấn công DDoS vừa qua nhắm vào GitHub và Greatfire.org, hai trong số nhiều online resource có chứa các nội dung mà phía China.gov cho là mang tính đe dọa tới họ.

Nhóm tác giả gọi hệ thống khủng khiếp này là Great Cannon (GC), cái tên dễ làm người ta liên tưởng tới một hệ thống kiểm duyệt nội dung (censorship) Internet khác cũng của China.gov là Great Firewall (GFW). Dưới đây là một số “key findings & conclusions” rút ra từ bản báo cáo này:

1) Thiết kế và hoạt động của GC

– GC là một hệ thống nằm giữa Global Internet và China Domestic Network. Nói cách khác, tất cả traffic Internet quốc tế đi vào/ra khỏi lãnh thổ China đều sẽ được chuyển hướng để đi tới GC. Sau đó, dựa trên một số tiêu chí mà traffic này có thể bị GC ngăn không cho lưu thông (drop packet), thay đổi hoặc chèn thêm thông tin (inject packet). Tóm lại, GC là một dạng full “man-in-the-middle” với khả năng can thiệp sâu vào kênh truyền giữa các máy tính ở trong và ngoài China.

– GC không xem xét tất cả traffic cần đi qua nó mà chỉ can thiệp đối với các traffic xuất phát từ một tập địa chỉ IP xác định. Điều này có lẽ là để giảm bớt gánh nặng cho GC khi mà tổng bandwidth quốc tế của China hiện xấp xỉ 1,9 terabits/s, một con số peak traffic cực kỳ lớn. Ngoài ra, GC chỉ soi packet đầu tiên của request rồi ra quyết định xử lý luôn (ignore, drop, inject) nên tránh được chi phí cho công đoạn ráp nối các TCP segment (TCP reassembly, như cách mà GFW làm). GC cũng duy trì một “connection flow cache” được dùng để bỏ qua các kết nối gần đây nhất mà không còn cần thiết phải theo dõi nữa.

2) GC và GFW có mối quan hệ như thế nào?

– Kết quả tracert cho thấy GC và GFW cùng nằm trong hạ tầng mạng thuộc quản lý của hai ISP lớn là China Telecom và China Unicom.

– Hai hệ thống này có một vài điểm giống nhau về thiết kế (multi-process cluster with different source IP addresses handled by distinct processes) và codebase (the same peculiar TTL side-channel).

– Về chức năng và hành vi thì có hơi khác biệt:

+ GFW với đóng vai trò là on-path system, statefull firewall: không đứng giữa đường lưu thông traffic Internet quốc tế vào/ra khỏi China mà thay vào đó là nghe lén kênh truyền (eavesdropping) như được chỉ ra bởi phần TAP trong hình vẽ trong báo cáo. Lúc này, để nắm rõ nội dung trao đổi (như truy cập website nào, search string là gì, có keyword nhạy cảm) thì nó phải thực hiện công đoạn TCP segment reassembly rồi sau đó mới đưa ra quyết định có nên phá đám hay không bằng cách gửi gói TCP Reset giả mạo khiến cho hai đầu kênh truyền tự hủy kết nối. Tuy nhiên, nếu một đầu kịp thời gửi đi gói tin cho đầu còn lại trước khi nhận gói TCP Reset trên thì GFW hiện sẽ không cản trở được. Do cách xử lý chưa triệt để đối với “in-flight packet” này mà một người vẫn có thể phát hiện ra GFW nếu quan sát các gói tin nhận được có hiện diện cả gói hợp lệ và gói bị giả mạo.

+ Với GC, như một in-path system: như đã dẫn ra ở trên, nó sẽ hứng trọn traffic giữa China với quốc tế và thực hiện cản lọc hay chèn thêm gói tin chỉ đối với một tập “targeted address” nào đó, “action” được đưa ra ngay khi nó xem xét packet đầu tiên của request có thỏa mãn “attack criteria” hay không. Ngoài ra, khác với GFW là không phải cứ thỏa mãn tiêu chí attack thì sẽ có action cụ thể mà qua thử nghiệm cho thấy GC có xác suất ra quyết định drop/inject khá thấp (khoảng 2%).

3) GC được dùng để tấn công DDoS nhằm vào GitHub ra sao?

Các bước dẫn tới hệ quả trên có thể được mô tả như sau:

1. User bên ngoài China truy cập vào một website nằm trong China. Trên website này có nhúng resource nằm trong “attack criteria” của GC, cụ thể ở đây là file Baidu Analytics javascript mà các webadmin thường dùng để thống kê lượng truy cập (kiểu như Google Analytics).
2. Khi GC bắt được request đầu tiên thỏa mãn điều kiện ở trên (yêu cầu tải về file javascript) thì nó sẽ không chuyển tiếp tới Baidu server mà thay vào đó gửi lại cho user một response giả mạo chứa file javascript độc hại khiến cho user liên tục reload một số URL của GitHub mà không hề hay biết.
3. Càng nhiều user bị như trên làm cho tình trạng DDoS tồi tệ và khó kiểm soát hơn.

Khả năng của GC không chỉ dừng lại ở đây là tấn công DDoS có chủ đích nữa mà nếu muốn thì hệ thống này có thể được tận dụng để theo dõi ai đó trên Internet có kết nối vào/ra China và rồi cũng thông qua các response giả mạo để tự động cài malware lên máy của họ.

4) Ai đứng đằng sau GC?

Bên cạnh mối liên hệ giữa GC và GFW thì việc các ISP lớn của China cùng tham gia vào mạng lưới hosting cho hệ thống này cho thấy khả năng cao có sự quản lý từ phía China.gov. Nếu thế thì đây là một sự đánh đổi không nhỏ khi đã đặt “political stability & national security” cao hơn lợi ích mà Baidu cũng như các công ty công nghệ khác ở China đang ăn nên làm ra như Alibaba, Tencent đóng góp vào market share và top ranking trên Internet, vì rõ ràng người dùng sẽ rất e ngại khi truy cập vào các website đặt trong China hoặc có ads network ở đó.

5) Phương thức nào giúp người dùng Internet có thể tự bảo vệ mình trước GC?

Nên ưu tiên truy cập các website có hỗ trợ full HTTPS (không có mixed content với link HTTP) vì GC chỉ khai thác được nếu nó có thể thấy luồng traffic không được bảo vệ bởi cơ chế mã hóa & xác thực do SSL/TLS cung cấp.

-mt.