Chiến dịch City-Forum: Một máy chủ duy nhất đánh cắp dữ liệu từ Salesforce và ServiceNow suốt 17 tháng mà không cần khai thác lỗ hổng

Trong suốt 17 tháng, một tác nhân đe dọa không rõ danh tính đã âm thầm rút các bản ghi từ các trang Salesforce Experience Cloud và ServiceNow Service Portal trên toàn cầu — mà không khai thác một lỗ hổng phần mềm nào, không đánh cắp thông tin đăng nhập, cũng không vượt qua xác thực. Kẻ tấn công chỉ đơn giản sử dụng những gì các tổ chức đã cho phép công chúng truy cập thông qua tính năng người dùng khách (anonymous) có sẵn trên nền tảng.

Hãng bảo mật Reco đã đặt tên cho chiến dịch đang diễn ra này là City-Forum, theo tên miền city-forum.com được đăng ký cho hạ tầng của kẻ tấn công. Kể từ ít nhất tháng 3 năm 2025, một máy chủ thuê duy nhất tại Đức đã có hệ thống thu thập dữ liệu từ các nhà cung cấp dịch vụ viễn thông, ngân hàng, công ty dịch vụ tài chính, nhà cung cấp phần mềm doanh nghiệp và các cổng thông tin khu vực công.

Cách thức khai thác: Không cần lỗ hổng

Cả Salesforce và ServiceNow đều được tích hợp sẵn các tài khoản người dùng khách cố định dành cho khách truy cập chưa xác thực. Không thể xóa các tài khoản khách này. Quyền hạn của chúng — những bản ghi và đối tượng nào mà khách có thể đọc — được cấu hình bởi mỗi tổ chức. Nếu hồ sơ khách có quyền đọc một bản ghi, bất kỳ ai trên internet đều có thể truy xuất nó thông qua các endpoint API hoàn toàn hợp lệ.

Trên Salesforce (framework Aura):

• Công cụ này gửi các yêu cầu POST tới endpoint /aura hoặc /s/sfsites/aura.
• Đầu tiên, nó gọi HostConfigController.getConfigData để liệt kê các đối tượng (Account, Contact, Case, Lead, User, ContentDocument, v.v.) mà khách có thể truy cập.
• Sau đó, nó sử dụng SelectableListDataProviderController.getItems để phân trang qua tất cả các bản ghi trên mỗi đối tượng có thể truy cập.
• Một mục tiêu bị tấn công nhiều nhất đã ghi nhận hơn 560.000 sự kiện từ IP của kẻ tấn công, hầu hết là liệt kê Aura của khách.

Trên Salesforce (framework LWR — Lightning Web Runtime):

• Đây là lần khai thác trong thực tế đầu tiên bề mặt UI-API dành cho khách trên các trang LWR của Salesforce.
• Công cụ này nhắm mục tiêu vào endpoint GraphQL tại

  POST /webruntime/api/services/data/{version}/graphql?asGuest=true

  , đầu tiên liệt kê schema thông qua EntityDefinition, sau đó đọc các bản ghi bằng cách phân trang dựa trên con trỏ (cursor).
• Nó quét qua các phiên bản API từ v56.0 đến v66.0 một cách tuần tự đối với mỗi trang LWR được phát hiện.

Trên ServiceNow:

• Công cụ này nhắm mục tiêu endpoint /api/now/sp/search — một API tìm kiếm Service Portal có sẵn nhưng hầu như không được ghi chép và hầu như không có tài liệu trực tuyến hay công cụ mã nguồn mở nào đề cập đến nó.
• Endpoint này được thiết kế để công khai. Dữ liệu mà nó trả về phụ thuộc hoàn toàn vào các nguồn tìm kiếm (search sources) được gắn với cổng dành cho khách và liệu các nguồn đó có thực thi kiểm soát truy cập hay không.

Dò tìm tự đăng ký (Salesforce):

• Công cụ này thêm /SiteRegister và /CommunitiesSelfReg vào mọi đường dẫn trang experience site được phát hiện để kiểm tra xem tính năng tự đăng ký có được bật hay không. Nếu có, khách có thể tự nâng cấp lên người dùng bên ngoài đã xác thực, từ đó truy cập được nhiều dữ liệu hơn.

Bộ công cụ tùy chỉnh và hạ tầng

• IP nguồn: 158.220.87.79, được lưu trữ trên VPS Contabo (nhà cung cấp dịch vụ lưu trữ Đức), phân giải tới tên miền city-forum.com (tên miền được đăng ký từ năm 2002, bị bỏ hoang, sau đó được tái sử dụng).
• Cùng một IP này đã mang cùng một tên miền kể từ tháng 3 năm 2025 mà không có sự thay đổi — ít nhất 17 tháng trên một địa chỉ.
• Tệp nhị phân Go tùy chỉnh: Một công cụ duy nhất được biên dịch bằng Go, có thể tấn công Salesforce trên cả hai framework Aura và LWR, đồng thời tấn công cả ServiceNow — tất cả từ cùng một máy chủ. Đây là một bộ công cụ đa nền tảng tùy chỉnh, không phải là một công cụ có sẵn như AuraInspector.
• Công cụ này sử dụng chuỗi User-Agent mặc định Go-http-client của Go, giúp dễ dàng nhận dạng trong nhật ký.

Các tổ chức bị nhắm mục tiêu

Reco báo cáo rằng các mục tiêu chính bao gồm:

• Các nhà khai thác viễn thông
• Ngân hàng và công ty dịch vụ tài chính
• Các nhà cung cấp phần mềm doanh nghiệp (bao gồm các công ty an ninh mạng và quyền riêng tư dữ liệu)
• Cổng thông tin khu vực công

Tại sao nhật ký kiểm toán tiêu chuẩn không thể tiết lộ dữ liệu nào đã bị lấy

Đối với ServiceNow: Nhật ký giao dịch của nền tảng (syslog_transaction) không ghi lại nội dung POST body của các yêu cầu /api/now/sp/search. Các nhà bảo vệ có thể thấy rằng các tìm kiếm tự động đã xảy ra và lượng dữ liệu đã được trả về (thông qua cột độ dài đầu ra), nhưng không thể xác định các cụm từ tìm kiếm chính xác hoặc bản ghi cụ thể nào đã được truy xuất.

Đối với Salesforce: Lưu lượng liệt kê của khách bao gồm các lệnh gọi API hợp lệ, tuân thủ giao thức, trông giống như lưu lượng trang web thông thường. Mặc dù Event Monitoring có thể hiển thị khối lượng các sự kiện AuraRequest và Sites từ người dùng khách, nhưng nhật ký chỉ cho thấy dữ liệu đã được yêu cầu chứ không phải nội dung cụ thể của những gì đã được trả về trong các phản hồi GraphQL hoặc Aura.

Nói cách khác, bạn có thể thấy kẻ tấn công đã ở đó và lượng dữ liệu chúng đã lấy, nhưng bạn không thể tái tạo chính xác bản ghi hoặc trường nào đã bị trích xuất.

Các bước khắc phục được khuyến nghị

Đối với Salesforce (khuyến nghị từ Reco):

1. Thắt chặt các quy tắc chia sẻ dành cho khách — biện pháp kiểm soát có tác động cao nhất. Xóa mọi quy tắc chia sẻ chia sẻ bản ghi với Người dùng khách ngoài những gì trang web thực sự cần để phục vụ công chúng.
2. Loại bỏ quyền đối với đối tượng và trường khỏi hồ sơ khách. Xóa quyền đọc trên các đối tượng mà trang web không cần cho khách truy cập ẩn danh.
3. Xóa quyền "Access Activities" khỏi hồ sơ khách (sẽ làm lộ Tasks và Events).
4. Tắt "API Enabled" trên người dùng khách.
5. Tắt tính năng tự đăng ký trừ khi trang web thực sự yêu cầu.
6. Tắt quyền truy cập tệp của khách và khả năng hiển thị thành viên để khách không thể truy xuất các tệp ContentDocument hoặc liệt kê các thành viên khác của trang.
7. Đối với các trang LWR: Trong Experience Builder → Workspaces → Administration → Preferences, bỏ chọn "Allow guest users to access public APIs." Thao tác này sẽ đóng GraphQL và các endpoint REST UI-API chỉ trong một lần.

Đối với ServiceNow (khuyến nghị từ Reco):

1. Lập bản đồ các cổng dành cho khách với các nguồn tìm kiếm của chúng. Kiểm tra các bảng sp_portal, m2m_sp_portal_search_source và sp_search_source. Tách rời mọi nguồn tìm kiếm mà cổng công cộng không cần.
2. Xem xét logic của từng nguồn tìm kiếm — đặc biệt là is_scripted_source, data_fetch_script và liệu nó có sử dụng GlideRecordSecure (thực thi ACL) hay GlideRecord thông thường (không thực thi).
3. Xem xét các tiêu chí người dùng "Can Read" của cơ sở kiến thức — tìm kiếm quyền truy cập "Bất kỳ người dùng nào" không bị ràng buộc, có thể làm lộ các cơ sở kiến thức nhạy cảm thông qua tìm kiếm của khách.
4. Tách các liên kết kb_uc_can_read_mtom không phù hợp thay vì chỉnh sửa các quy tắc chia sẻ một cách mù quáng.

Hướng dẫn phát hiện:

• Salesforce Event Monitoring: Tìm kiếm khối lượng lớn getItems và getConfigData từ

  USER_TYPE = 'Guest'

  , quét phiên bản /webruntime/.../vNN.0/graphql và các yêu cầu truy cập /SiteRegister và /CommunitiesSelfReg.
• ServiceNow syslog_transaction: Tìm kiếm các yêu cầu /api/now/sp/search được thực hiện với tư cách khách. Sắp xếp theo độ dài đầu ra — các hàng trả về nhiều hơn đáng kể so với đường cơ sở kết quả trống nhỏ cho thấy các tìm kiếm đã trả về nội dung.