7 rủi ro bảo mật ứng dụng có thể phòng ngừa

1. Giới thiệu#

Các tập đoàn lớn, bao gồm Uber, MGM Resorts, CircleCI, Ticketmaster và nhiều doanh nghiệp khác, đã phải đối mặt với các vụ vi phạm bảo mật từ tháng 9 năm 2022 đến tháng 5 năm 2024 sau khi những kẻ tấn công giành được quyền truy cập trái phép vào hệ thống tài khoản người dùng của họ. Các cuộc tấn công đã gây ra thiệt hại hơn hàng trăm triệu đô la đồng thời làm lộ dữ liệu cá nhân của hơn 600 triệu người dùng và hệ thống xác thực lỗi thời lúc bấy giờ đã có thể ngăn chặn các vụ vi phạm bảo mật này.

Câu chuyện cho thấy không có bằng chứng nào về việc những kẻ tấn công an ninh mạng sử dụng các lỗ hổng chưa được biết (zero-days) tinh vi để tiến hành các cuộc tấn công của họ. Những trường hợp này tiết lộ cách các tổ chức đã thất bại trong việc ngăn chặn các vụ vi phạm bảo mật. Hầu hết đều nhận thức được các cuộc tấn công gây mệt mỏi MFA nhưng lại không bảo vệ được trước chúng, và họ nhận ra các lỗ hổng hệ thống dựa trên mật khẩu nhưng vẫn tiếp tục sử dụng chúng.

2. Thất bại của hệ thống xác thực cũ#

Hệ thống xác thực yếu hoặc lỗi thời là điểm xâm nhập phổ biến đối với những kẻ tấn công. Phần lớn các vụ vi phạm bảo mật bắt đầu với việc kẻ tấn công lấy được mật khẩu bị đánh cắp hoặc đã sử dụng trước đó, mặc dù các tổ chức có quyền truy cập vào các hệ thống xác thực passkey đã được thiết lập, cung cấp khả năng bảo vệ chống lừa đảo. Vụ vi phạm MGM Resorts năm 2023 bắt đầu khi những kẻ tấn công sử dụng vishing để gọi bộ phận hỗ trợ IT, cho phép chúng thiết lập lại thông tin xác thực và sau đó triển khai ransomware gây gián đoạn hệ thống trong bảy ngày.

Hệ thống bảo mật của MGM và các tổ chức khác đã sử dụng mật khẩu cùng với xác thực hai yếu tố dựa trên SMS, điều này không bảo vệ được trước các cuộc tấn công kỹ nghệ xã hội và đánh cắp thông tin xác thực. Tổ chức đã không thiết lập các hệ thống xác thực tốt hơn vì họ hiểu các mối đe dọa bảo mật, nhưng hệ thống và quy trình làm việc hiện tại của họ đã ngăn cản họ thực hiện các thay đổi.

Passkey, sử dụng mật mã khóa công khai và nhận dạng sinh trắc học, sẽ giảm đáng kể nguy cơ thành công của các cuộc tấn công này. Passkey an toàn hơn mật khẩu vì người dùng không thể thiết lập lại chúng thông qua truy cập từ xa hoặc bộ phận hỗ trợ bằng cách chia sẻ mã thiết lập lại, điều này bảo vệ trước các cuộc tấn công kỹ nghệ xã hội. Tuy nhiên, tính bảo mật của passkey vẫn dễ bị tổn thương trước các phương pháp tấn công cụ thể, xảy ra khi quy trình khôi phục tài khoản không được bảo mật đúng cách và khi thiết bị bị nhiễm phần mềm độc hại.

3. Các cuộc tấn công dựa trên phiên và cookie#

Những kẻ tấn công tập trung vào việc lấy cookie vì chúng sẽ giúp giành quyền truy cập hệ thống và vượt qua mọi quy trình xác thực. Vụ vi phạm CircleCI năm 2022 nhấn mạnh điều này bằng cách cho thấy một phần mềm độc hại infostealer trên máy tính xách tay của nhân viên có thể dễ dàng đánh cắp cookie phiên hoạt động. Bằng cách sử dụng những cookie này, những kẻ tấn công sau đó đã vượt qua xác thực hai yếu tố và giành quyền truy cập vào hệ thống sản xuất.

Cookie phiên đóng vai trò như một phương tiện để vượt qua các biện pháp kiểm soát truy cập bằng bearer token của chúng, tạo điều kiện cho việc lộ dữ liệu nhạy cảm. Để ngăn chặn những sự cố như vậy, các tổ chức có thể triển khai Thông tin xác thực phiên liên kết thiết bị (DBSC), giúp bảo vệ người dùng khỏi việc đánh cắp phiên bằng cách sử dụng các phương pháp mã hóa để liên kết các phiên với các thiết bị cụ thể. Điều này khiến cho các cookie bị đánh cắp từ các máy tính khác không thể sử dụng được. Hệ thống DBSC cung cấp sự bảo vệ hiệu quả chống lại phần mềm độc hại infostealer chạy trên các thiết bị khác nhau, nhưng nó không thể ngăn chặn các cuộc tấn công khi phần mềm độc hại lây nhiễm vào thiết bị được đăng ký ban đầu.

4. Lỗi ủy quyền (Broken Authorization)#

Khi những kẻ tấn công chọc thủng kiểm soát truy cập trong ứng dụng, chúng có thể di chuyển ngang mà không cần quan tâm đến các quyền của mình. Rủi ro bảo mật từ các lỗ hổng ủy quyền tiếp tục ở mức cao do những kẻ tấn công đã thành công sử dụng các biện pháp kiểm soát truy cập không đủ chặt chẽ để điều hướng giữa các thành phần hệ thống trong nhiều vụ vi phạm mạng.

Để xác định các lỗ hổng IDOR (Tham chiếu đối tượng trực tiếp không an toàn), các nhà phát triển ứng dụng nên sử dụng mô hình hóa mối đe dọa dựa trên khái niệm để phát hiện cấu trúc quản lý truy cập cơ bản và triển khai quy trình đánh giá mã để xác thực quyền tài khoản dịch vụ.

Việc chọn cấu hình phân công vai trò và quản lý quyền phức tạp thay vì mô hình đặc quyền tối thiểu có thể khiến các tổ chức dễ gặp các vấn đề về ủy quyền. Phân công vai trò phức tạp có thể dẫn đến việc truy cập trái phép vào các chức năng và thông tin nhạy cảm trong các ứng dụng hướng tới khách hàng. Các tổ chức không có khung ủy quyền bảo mật không thể bảo vệ dữ liệu của họ khỏi việc truy cập và thao tác trái phép.

Với sự gia tăng các vấn đề bảo mật B2C, một tài khoản bị xâm phạm có thể gây ra thiệt hại đáng kể cho nhiều tài khoản người dùng. Bằng cách thực hiện quản lý truy cập đặc quyền, các tổ chức có thể cấp cho nhân viên và khách hàng của mình chỉ mức truy cập tối thiểu cần thiết để hoàn thành công việc của họ. Thêm vào đó, mô hình hóa mối đe dọa dựa trên khái niệm và đánh giá mã thường xuyên có thể giúp phát hiện rủi ro và lỗ hổng một cách dễ dàng.

5. Tích hợp AI không an toàn#

Sự tích hợp nhanh chóng của GenAI và LLM vào các ứng dụng đã vượt qua khả năng của các biện pháp kiểm soát truyền thống trong việc phát hiện những thay đổi này, dẫn đến một rủi ro bảo mật chưa từng thấy. Vụ vi phạm Snowflake năm 2024 chứng minh cách các tác nhân đe dọa sử dụng thông tin xác thực bị đánh cắp từ các cuộc tấn công của phần mềm độc hại infostealer để xâm nhập vào môi trường khách hàng Snowflake, vốn không triển khai xác thực đa yếu tố. Cuộc tấn công đã làm ảnh hưởng tới hơn 165 tổ chức, bao gồm Ticketmaster với 560 triệu hồ sơ khách hàng, AT&T và Ngân hàng Santander.

Các tổ chức thường không công nhận AI như một phần cốt lõi của môi trường IT, khiến các tài nguyên AI như mô hình, kho lưu trữ dữ liệu vector hóa và quy trình AI dễ bị cấu hình sai và rủi ro tấn công mạng. Hầu hết các tổ chức đều gặp khó khăn trong việc giám sát hệ thống AI hiệu quả do "shadow AI," nơi các cá nhân không được ủy quyền có thể thực hiện các cuộc tấn công dựa trên thông tin xác thực mà không bị phát hiện nội bộ.

Nếu các tổ chức áp dụng các biện pháp kiểm soát cơ bản như xác thực đầu vào, cách ly và giám sát liên tục cho hệ thống AI của họ như làm với các cơ sở hạ tầng IT khác, những sự cố bảo mật này có thể đã tránh được. Các tổ chức có thể tự động hóa việc xác định và khắc phục các cấu hình sai bằng cách sử dụng các công cụ bảo mật AI, cung cấp kho lưu trữ đầy đủ tất cả tài nguyên AI.

6. Cấu hình sai đám mây và môi trường thời gian chạy (Runtime)#

Cấu hình sai trên đám mây, bao gồm các storage bucket bị lộ, nhóm bảo mật (security groups) quá mức cho phép và bộ chứa (containers) bị lộ, có thể dẫn đến các sự cố bảo mật. Vụ vi phạm ePallet năm 2022 cho thấy một bucket Amazon S3 bị cấu hình sai có thể làm lộ dữ liệu khách hàng nhạy cảm của các doanh nghiệp khác đang sử dụng công cụ của họ. Những kẻ tấn công đã sử dụng hai vector chính để truy cập thông tin nhạy cảm: storage bucket không được bảo vệ và các nhóm bảo mật có kiểm soát truy cập không hiệu quả.

Quét Tuân thủ Cơ bản (Basic Compliance Scanning) cho thấy các cuộc tấn công này bắt nguồn từ hai nguồn chính: bộ nhớ lưu trữ có thể truy cập công khai chứa dữ liệu cụ thể của người dùng và các cổng quản lý ảo bị lộ. Các tổ chức có thể coi các cấu hình sai này là các bản sửa lỗi ngắn hạn cho mục đích tuân thủ, nhưng hầu hết lại trở thành điểm vi phạm bảo mật.

Việc xác định và khắc phục các cấu hình sai nên diễn ra liên tục thông qua quản lý tư thế bảo mật đám mây (CSPM) liên tục hoặc kiểm tra bảo mật thời gian chạy (runtime), giúp giảm đáng kể rủi ro bị kẻ tấn công khai thác lỗ hổng. Các tổ chức có thể sử dụng các công cụ quét và giám sát tự động để tìm kiếm cấu hình sai, sau đó nền tảng giám sát có thể khắc phục chúng.

7. Thiếu bảo mật trong SDLC#

Các lỗ hổng xâm nhập vào quá trình sản xuất khi các chức năng bảo mật không được tích hợp đúng cách vào quy trình phát triển phần mềm. Một cấu hình sai trên GitHub action trong quy trình CI/CD của một công ty khởi nghiệp tiền điện tử đã âm thầm chia sẻ thông tin xác thực AWS, giúp những kẻ tấn công khai thác tiền điện tử trị giá $800.

SAST/DAST, đánh giá mã an toàn và quét phụ thuộc (dependency scanning) có thể xác định các lỗ hổng bảo mật phổ biến. Chúng có thể từ các cuộc tấn công injection đến deserialization không an toàn và tham chiếu đối tượng trực tiếp không an toàn, nhưng những vấn đề này sẽ tiếp diễn nếu bảo mật không được chú ý.

Tích hợp bảo mật vào quy trình phát triển phần mềm (SDLC) cho phép các nhà phát triển xác định và giải quyết các lỗ hổng bảo mật, mà họ có thể thực hiện trong các ứng dụng web của mình trước khi triển khai lên môi trường sản xuất. Việc ngăn ngừa các vấn đề này đòi hỏi các tổ chức phải thực hiện ba thực tiễn bảo mật cơ bản: quét tự động, quản lý phụ thuộc và đánh giá mã an toàn.

8. Quy trình giám sát và khắc phục không đầy đủ#

Các tổ chức tiếp tục gặp các vụ vi phạm bảo mật phần lớn do họ không thể nhận ra các chỉ báo cảnh báo và thiếu quy trình khắc phục được xác định cho các bất thường của hệ thống. Họ nên giám sát nhất quán các hệ thống máy tính của mình và thiết lập quy trình phản hồi rõ ràng đối với các vi phạm bảo mật, theo các tiêu chuẩn ngành hiện tại được đúc kết từ vụ vi phạm Uber năm 2022. Không có ghi log toàn diện cho các sự kiện bảo mật, các tổ chức sẽ gặp khó khăn trong việc theo dõi credential stuffing (nhồi nhét thông tin xác thực), các nỗ lực truy cập thiết bị bất thường hoặc các giao dịch token bất thường.

Các tổ chức cảm thấy khó khăn trong việc phát hiện các nỗ lực xác thực và đăng nhập hoặc ghi lại các sự kiện đăng ký của người dùng vì thông tin họ thu thập thiếu chi tiết đủ để xác định sớm việc lạm dụng quyền bảo mật.

Hệ thống của tổ chức xác định và quản lý các sự kiện bất thường thông qua dữ liệu đo từ xa (telemetry) tập trung vào quyền riêng tư và các quy trình phản hồi theo thuật toán tự động. Các khả năng phát hiện và phản hồi bằng AI sẽ giúp các tổ chức xác định mối liên hệ giữa các sự kiện bảo mật và ngăn chặn các vụ vi phạm xảy ra.

9. Kết luận#

Phần đáng thất vọng nhất khi nghiên cứu về các vụ vi phạm MGM, Snowflake, Uber và CircleCI là hiểu rằng những sự cố này có thể tránh được. Sự cố trở nên không thể tránh khỏi do công nghệ hiện tại thiếu các khả năng cần thiết mà các doanh nghiệp chú trọng bảo mật đã sử dụng cho hệ thống xác thực của họ.

Tất cả các tổ chức trong báo cáo này đều có quyền truy cập để triển khai passkey trước khi hệ thống của họ bị vi phạm. Mặc dù passkey là công nghệ trưởng thành có sẵn trong giai đoạn 2022-2024, Thông tin xác thực phiên liên kết thiết bị (DBSC) chưa khả dụng rộng rãi cho đến năm 2024. Hệ thống bao gồm nhiều biện pháp kiểm soát bảo mật đám mây, như thực thi MFA, danh sách cho phép (allowlist) mạng, IAM đặc quyền tối thiểu và giám sát. Tuy nhiên, các biện pháp kiểm soát này cần thiết lập thủ công để bảo vệ hoàn toàn.

Đội ngũ bảo mật của một số tổ chức đã hỗ trợ các biện pháp kiểm soát này, nhưng họ không vượt qua được sự kháng cự thay đổi trên toàn công ty. Hậu quả là dữ liệu cá nhân của hơn 600 triệu người bị lộ, các cuộc điều tra pháp lý và tổng thiệt hại vượt mức hàng trăm triệu đô la.

Các tổ chức đã tiến hành nghiên cứu chứng minh rằng các cuộc tấn công dựa trên thông tin xác thực sẽ gia tăng với tốc độ ngày càng nhanh, do đó các tổ chức cần xử lý ngay lập tức mối đe dọa bảo mật nghiêm trọng này. Tổ chức của bạn cần xác định xem sẽ áp dụng hệ thống xác thực hiện đại trước hay sau khi các tổ chức khác dùng sự thất bại bảo mật của bạn làm ví dụ trong các cuộc điều tra vi phạm của họ.

Các công cụ bảo mật ứng dụng đã tồn tại và chúng hoạt động tự động thông qua quy trình đơn giản không cần các quy trình cài đặt phức tạp. Hệ số hoàn vốn (ROI) có thể đo lường được. Cộng đồng bảo mật thiếu cảm giác cấp bách, điều này có thể giúp họ nhận ra hiện đại hóa xác thực là một kiểm soát bảo mật thiết yếu. Tổ chức cần hành động ngay lập tức vì cuộc gọi hỗ trợ help desk, email lừa đảo (phishing) và payload của infostealer tiếp theo sẽ phát triển thành sự cố tốn kém hàng trăm triệu đô la.

Về Corbado

Corbado là Passkey Intelligence Platform dành cho các đội CIAM vận hành xác thực consumer ở quy mô lớn. Chúng tôi giúp bạn nhìn thấy điều mà log IDP và các công cụ analytics thông thường không thấy: những thiết bị, phiên bản OS, trình duyệt và trình quản lý credential nào hỗ trợ passkey, tại sao quá trình đăng ký không chuyển thành đăng nhập, luồng WebAuthn fail ở đâu, và khi nào một bản cập nhật OS hay trình duyệt làm hỏng đăng nhập một cách âm thầm — tất cả mà không cần thay thế Okta, Auth0, Ping, Cognito hay IDP nội bộ của bạn. Hai sản phẩm: Corbado Observe bổ sung observability cho passkey và mọi phương thức đăng nhập khác. Corbado Connect mang đến managed passkey với analytics tích hợp (song hành cùng IDP của bạn). VicRoads vận hành passkey cho hơn 5M người dùng với Corbado (kích hoạt passkey +80%). Trao đổi với chuyên gia Passkey →

Những câu hỏi thường gặp#

Làm thế nào mà vụ vi phạm CircleCI lại vượt qua xác thực hai yếu tố?#

Trong vụ vi phạm CircleCI năm 2022, phần mềm độc hại infostealer trên máy tính xách tay của nhân viên đã đánh cắp trực tiếp các cookie phiên hoạt động. Bởi vì cookie phiên hoạt động như các bearer token cấp quyền truy cập ngay lập tức, kẻ tấn công đã sử dụng chúng để vượt qua hoàn toàn xác thực hai yếu tố và tiếp cận các hệ thống sản xuất.

Sự khác biệt giữa DBSC và cookie phiên tiêu chuẩn về mặt bảo mật là gì?#

Cookie phiên tiêu chuẩn có thể bị đánh cắp bởi phần mềm độc hại infostealer và tái sử dụng từ bất kỳ thiết bị nào, qua mặt các biện pháp kiểm soát xác thực. Thông tin xác thực phiên liên kết thiết bị (DBSC) sử dụng các phương pháp mã hóa để liên kết một phiên với thiết bị cụ thể đã tạo ra nó, vì vậy cookie bị đánh cắp không thể phát lại từ các máy do kẻ tấn công kiểm soát.

Tại sao lỗi kiểm soát truy cập lại gây ra thiệt hại trên diện rộng như vậy trong vụ vi phạm Snowflake?#

Vụ vi phạm Snowflake đã xâm phạm hơn 165 tổ chức khách hàng vì môi trường khách thuê (tenant) cá nhân thiếu việc thực thi MFA, nghĩa là một bộ thông tin xác thực bị đánh cắp có thể mở khóa toàn bộ kho dữ liệu khách hàng. Chỉ riêng Ticketmaster đã có 560 triệu hồ sơ khách hàng bị lộ do lỗ hổng kiểm soát duy nhất này.

Lỗi bảo mật SDLC nào đã dẫn đến sự cố đào tiền điện tử qua GitHub Actions?#

Một luồng công việc GitHub Actions bị cấu hình sai trong quy trình CI/CD của một công ty khởi nghiệp tiền điện tử đã âm thầm rò rỉ thông tin xác thực AWS cho những kẻ tấn công, những người đã sử dụng chúng để đào 800 USD tiền điện tử. Bài viết xác định quét SAST/DAST tự động, quản lý phụ thuộc và đánh giá mã nguồn an toàn là ba thực tiễn có thể đã phát hiện ra cấu hình sai này trước khi triển khai sản xuất.