Cảnh Báo: Tấn công tinh vi vào máy chủ Nginx để điều hướng lưu lượng

Các nhà nghiên cứu bảo mật tại DataDog Security Labs vừa phát hiện một chiến dịch tấn công mạng mới với mức độ tinh vi cao, nhắm trực tiếp vào các máy chủ web sử dụng NGINX. Thay vì khai thác các lỗ hổng phần mềm (vulnerabilities) truyền thống, nhóm tin tặc này (threat actor) sử dụng kỹ thuật “cấu hình độc hại” để âm thầm chiếm đoạt và điều hướng lưu lượng truy cập của người dùng qua hệ thống máy chủ của chúng.

Ảnh: Datadog

1. Tổng quan về Mục tiêu và Phạm vi tấn công

NGINX hiện là phần mềm mã nguồn mở phổ biến nhất thế giới trong việc quản lý lưu lượng web, đóng vai trò quan trọng làm máy chủ web, cân bằng tải (load balancing) và proxy ngược (reverse proxy). Chính sự phổ biến này khiến NGINX trở thành mục tiêu giá trị cao.

Chiến dịch hiện tại tập trung vào hai nhóm đối tượng cụ thể:

Hạ tầng quản lý bằng Baota (Baota Panel): Đây là công cụ quản lý hosting rất phổ biến, thường được tin tặc nhắm đến do sự phổ biến và đôi khi là cấu hình lỏng lẻo.
Các tên miền mục tiêu: Nhóm tấn công đặc biệt chú ý đến các tên miền cấp cao (TLD) tại khu vực Châu Á (.in, .id, .pe, .bd, .th) và khối Chính phủ/Giáo dục (.gov, .edu).

2. Cơ chế tấn công: Ẩn mình dưới vỏ bọc Hợp Pháp

Sự nguy hiểm của chiến dịch này nằm ở chỗ tin tặc không cần đến các kỹ thuật khai thác phức tạp như tràn bộ đệm (buffer overflow) hay thực thi mã từ xa (RCE). Thay vào đó, chúng lạm dụng chính các tính năng chính chủ của NGINX.

Kỹ thuật Configuration Injection

Tin tặc xâm nhập và chèn các khối lệnh location mới vào tệp cấu hình NGINX. Các khối lệnh này được thiết kế tinh vi để bắt các yêu cầu truy cập (request) đến những đường dẫn URL cụ thể.

Quy trình chiếm đoạt lưu lượng diễn ra theo 4 bước:

Capture (Bắt gói tin): NGINX nhận request từ người dùng truy cập vào website bị nhiễm.
Rewrite (Viết lại): Cấu hình độc hại viết lại request để bao gồm URL gốc đầy đủ.
Forward (Chuyển tiếp): Sử dụng chỉ thị proxy_pass để chuyển tiếp lưu lượng này đến tên miền do kẻ tấn công kiểm soát.
Preserve (Giữ nguyên dấu vết): Các tiêu đề HTTP quan trọng như Host, X-Real-IP, User-Agent, và Referer được giữ nguyên.

Lưu ý chuyên môn: proxy_pass là chỉ thị tiêu chuẩn dùng để cân bằng tải. Việc lạm dụng nó giúp lưu lượng độc hại trông hoàn toàn giống với hoạt động hệ thống bình thường, qua mặt hầu hết các hệ thống giám sát an ninh cơ bản.

3. Phân tích bộ công cụ tấn công (The Toolkit)

Nhóm tin tặc triển khai một bộ công cụ đa giai đoạn (multi-stage toolkit) được viết bằng shell script, hoạt động tuần tự với cơ chế dự phòng mạnh mẽ.

Giai đoạn 1: Trình điều khiển khởi tạo (`zx.sh`)

Đây là script đóng vai trò người mở đường. Nhiệm vụ chính là tải xuống và thực thi các giai đoạn tiếp theo.

Điểm nổi bật: Script này tích hợp cơ chế dự phòng thông minh. Nếu các công cụ tải file tiêu chuẩn như curl hay wget không có sẵn trên máy chủ, nó sẽ tự động chuyển sang gửi yêu cầu HTTP thô (raw HTTP requests) thông qua giao thức TCP để tải payload.

Giai đoạn 2: Tấn công nền tảng Baota (`bt.sh`)

Script này được thiết kế riêng cho các máy chủ quản lý bằng Baota.

Nó đọc giá trị server_name để chọn mẫu cấu hình (injection template) phù hợp.
Thực hiện ghi đè cấu hình một cách an toàn và tải lại (reload) NGINX để tránh gây gián đoạn dịch vụ (downtime), giúp che giấu hành vi tấn công.

Giai đoạn 3: Xử lý cấu hình nâng cao (`4zdh.sh`)

Đây là giai đoạn phức tạp nhất, nhắm vào các thư mục cấu hình chuẩn như sites-enabled, conf.d, và sites-available.

An toàn hệ thống: Sử dụng các công cụ xử lý văn bản mạnh mẽ như csplit và awk để đảm bảo file cấu hình không bị lỗi cú pháp (syntax error) sau khi chỉnh sửa.
Kiểm soát phiên bản: Sử dụng hàm băm (hashing) và file ánh xạ (mapping file) để phát hiện các lần tiêm nhiễm trước đó, tránh việc chèn trùng lặp.
Xác thực: Luôn chạy lệnh nginx -t để kiểm tra tính hợp lệ của cấu hình trước khi reload.

Giai đoạn 4: Mục tiêu đặc thù (`zdh.sh`)

Script này thu hẹp phạm vi tấn công, tập trung chủ yếu vào thư mục /etc/nginx/sites-enabled và ưu tiên các tên miền .in và .id.

Cơ chế này tương tự giai đoạn 3 nhưng bao gồm một phương án mạnh tay hơn: nếu việc reload thất bại, nó sẽ ép buộc khởi động lại dịch vụ bằng lệnh pkill.

Giai đoạn 5: Thu thập và Trích xuất dữ liệu (`ok.sh`)

Sau khi thiết lập thành công, script này quét toàn bộ các cấu hình đã bị xâm nhập để lập bản đồ hệ thống, bao gồm:

Danh sách các tên miền bị chiếm đoạt.
Các mẫu template đã sử dụng.
Mục tiêu proxy. Toàn bộ dữ liệu này được gửi về máy chủ điều khiển (C2) tại địa chỉ IP 158.94.210.227.

4. Tại sao rất khó phát hiện?

Các chuyên gia an ninh mạng đánh giá đây là chiến dịch tàng hình hiệu quả vì:

Không dựa trên CVE: Các trình quét lỗ hổng (vulnerability scanners) sẽ báo cáo hệ thống An toàn vì NGINX vẫn là phiên bản sạch, không có mã độc nhị phân.
Trải nghiệm người dùng không đổi: Lưu lượng vẫn đến đích cuối cùng. Người dùng và quản trị viên không thấy lỗi kết nối hay chậm trễ đáng kể.

5. Hướng dẫn rà soát và khắc phục

Để bảo vệ hệ thống, quản trị viên cần thực hiện ngay các bước kiểm tra sau:

Bước 1: Rà soát dấu hiệu xâm nhập (IoC)

Chạy các lệnh sau trong terminal để tìm kiếm các chỉ thị nghi vấn trong thư mục cấu hình (thường là /etc/nginx/ hoặc /usr/local/nginx/):

# Tìm kiếm chỉ thị proxy_pass (Cần review thủ công các đích đến lạ)
grep -r "proxy_pass" /etc/nginx/

# Tìm kiếm các lệnh rewrite đáng ngờ
grep -r "rewrite" /etc/nginx/

# Tìm kiếm IP C2 đã biết của chiến dịch này
grep -r "158.94.210.227" /etc/nginx/

Cảnh báo: Nếu phát hiện proxy_pass trỏ đến một tên miền lạ hoặc IP không thuộc hệ thống backend của doanh nghiệp, máy chủ khả năng cao đã bị xâm nhập.

Bước 2: Kiểm tra các tệp `include`

Tin tặc thường ẩn mình trong các tệp cấu hình phụ. Hãy kiểm tra file nginx.conf để xem các dòng include:

include /etc/nginx/conf.d/*.conf;
include /etc/nginx/sites-enabled/*;

Hãy mở thư mục conf.d và sites-enabled, kiểm tra xem có tệp lạ nào được tạo ra gần đây không (ví dụ: aaaa.conf, backdoor.conf hoặc các tên tệp ngẫu nhiên).

Bước 3: Giải pháp lâu dài

Giám sát tính toàn vẹn tệp tin (FIM – File Integrity Monitoring): Cài đặt các công cụ như Tripwire, OSSEC hoặc Wazuh. Cấu hình để hệ thống gửi cảnh báo ngay lập tức khi có bất kỳ thay đổi nào (dù là nhỏ nhất) trong thư mục /etc/nginx/.
Siết chặt quyền truy cập (Hardening):

Đảm bảo user chạy NGINX không có quyền ghi (write permission) vào thư mục cấu hình.
Bảo vệ SSH: Sử dụng SSH Key, đổi port mặc định và hạn chế IP truy cập.
Bảo vệ Panel quản trị (như Baota): Đặt mật khẩu mạnh và sử dụng xác thực 2 lớp (nếu có).

Giám sát mạng (Network Monitoring): Theo dõi lưu lượng outbound từ máy chủ web. Một máy chủ web thông thường hiếm khi chủ động kết nối đến các server lạ bên ngoài trừ khi được cấu hình cụ thể.

Kết Luận

Vụ việc này là hồi chuông cảnh tỉnh cho thấy bảo mật website không chỉ dừng lại ở lớp ứng dụng (Application Layer) hay vá lỗ hổng phần mềm. Việc bảo vệ lớp hạ tầng (Infrastructure Layer) và giám sát tính toàn vẹn của cấu hình (Configuration Integrity) là yếu tố sống còn. Quản trị viên cần mở rộng quy trình kiểm tra định kỳ sang cả các tệp cấu hình hệ thống để đảm bảo an toàn tuyệt đối.