Chủ server NTP cá nhân bất ngờ bị Tesla "tấn công mạng" suốt nhiều tuần

Một quản trị viên vận hành NTP server tình nguyện cho pool.ntp.org phát hiện hàng chục nghìn request khai thác lỗ hổng nhắm vào IP của mình, tất cả đều mang header giả danh tên miền con của Tesla.

Sự việc không gây thiệt hại nhưng phơi bày lỗ hổng trong cách các công cụ quản lý bề mặt tấn công tự động xác định phạm vi quét. Đây là lời nhắc nhở đáng chú ý cho bất kỳ ai vận hành hạ tầng dùng chung trên Internet.

Chuyện gì đã xảy ra?

Robin, chủ server dreamstation.systems (IP 67.215.249.229), cho biết anh phát hiện điều bất thường khi kiểm tra log nginx. Ba địa chỉ IP liên tục gửi lưu lượng tấn công đến server anh:

• 54.165.75.96
• 35.168.63.24
• 52.44.200.251

Điểm kỳ lạ là các request này mang header Host hoặc Referer là pool-ntp.tesla.com, dùng user agent của Assetnote và cố gắng ép server gọi ngược về các URL callback của Assetnote.

Cả ba IP đều thuộc Amazon Web Services (AS AMAZON-AES), phù hợp với hạ tầng mà Assetnote — công cụ quản lý bề mặt tấn công nay thuộc Searchlight Cyber — sử dụng để quét tự động.

Giả thuyết: Assetnote thu thập mọi thứ tìm thấy dưới tên miền tesla.com, bao gồm pool-ntp.tesla.com. Tên miền con này trỏ CNAME tới pool.ntp.org — hệ thống round-robin gồm hàng nghìn NTP server tình nguyện — và có thể phân giải tới máy của Robin. Hệ thống lưu IP đó như một tài sản của Tesla, rồi bắt đầu ném exploit vào một người lạ hoàn toàn.

Mức độ "tấn công"

Chủ server cho biết kẻ quét đã thử đủ loại chiêu: leo thang đường dẫn (path traversal), tải webshell, dò nội bộ phần mềm, thăm dò các endpoint quản trị WordPress và CMS, SSRF, Log4Shell và nhiều hơn nữa.

Một số con số đáng chú ý:

• 989 request nhúng hostname assetnote-callback.com để phát hiện Log4Shell và Text4Shell
• 114 request gọi canary.assetnotessrf.com để phát hiện SSRF
• Hơn 50.000 request từ các host Assetnote kể từ ngày 21 tháng 8

Đáng chú ý, có 15 request mang header Host là login.solarcity.com, đều yêu cầu GET /(S(x))/b/(S(x))in/System.Web.Mvc.dll — một thủ thuật ASP.NET nhằm biến /b/(S(x))in/ thành /bin/.

Trong các template còn lộ ra hostname của bên thứ ba như servicemcdonalds.com, saferas.com, enrichcs.com.au, disneyfineart.com, và cả một địa chỉ nội bộ theo chuẩn RFC 1918 là 192.168.178.222.

Điều thú vị là scanner còn thử nói chuyện HTTP trên mọi cổng tìm được, khiến các dịch vụ SSH, Postfix và Dovecot của Robin cũng nhận vô số lưu lượng HTTP rác.

Phản ứng từ phía Tesla

Robin đã gửi email tới [email protected] nhưng chưa nhận được hồi âm. Nội dung email nhấn mạnh:

"Không có lỗ hổng nào ở Tesla, và tôi cũng không đòi hỏi gì cả. Tôi chỉ muốn báo rằng có thể các bạn đang vô tình gây phiền phức."

Từ ngày 8 tháng 9, anh bắt đầu trả về mã trạng thái 299 phi tiêu chuẩn cho mọi request mang Host pool-ntp.tesla.com, kèm nội dung giải thích rằng đây không phải hạ tầng của Tesla mà chỉ là server cá nhân. Tuy vậy, tình trạng này vẫn chưa chấm dứt.

Robin chia sẻ thêm rằng bản thân anh có thể chặn tường lửa các IP kia, nhưng chọn không làm vậy vì muốn quan sát và mong có người ở Tesla nhận ra vấn đề.

Liệu toàn bộ NTP Pool có bị ảnh hưởng?

Khi hỏi cộng đồng vận hành NTP Pool, một quản trị viên khác là Matt Nordhoff xác nhận cũng bị tấn công từ ngày 15 tháng 8, với hơn 22.000 request từ ba IP kể trên. Tuy nhiên, chưa có ai khác lên tiếng.

Câu hỏi còn bỏ ngỏ là liệu scanner có phân giải lại pool-ntp.tesla.com mỗi lần chạy — và tấn công mọi IP mà hệ thống định vị địa lý cho phép chạm tới — hay chỉ gom một vài IP rồi "đập" liên tục vào đó.

Bài học cho cộng đồng công nghệ

Sự việc phản ánh một vấn đề ngày càng phổ biến: các công cụ quét bề mặt tấn công tự động có thể hiểu sai phạm vi quét khi một tên miền CNAME trỏ sang hạ tầng dùng chung của bên thứ ba.

Với những ai vận hành NTP Pool, DNS round-robin hay bất kỳ dịch vụ phân tải nào tương tự, đây là lời cảnh tỉnh: đừng đặt CNAME dưới tên miền của mình trỏ tới hạ tầng tập thể không thuộc quyền kiểm soát. Cách làm đúng là dùng vendor zone (như 2.vn.pool.ntp.org) thay vì tự tạo tên miền con.

Câu chuyện cũng cho thấy vai trò của log chi tiết và giao tiếp có trách nhiệm trong cộng đồng bảo mật: thay vì chặn im lặng, việc ghi lại bằng chứng và báo cáo minh bạch giúp các tổ chức lớn nhìn ra lỗ hổng trong quy trình của chính họ.