“Nói một cách ẩn dụ, công việc của tôi ở Atlassian là phạm tội và sau đó viết những lá thư thú tội đầy chi tiết.”

Alex, một kỹ sư của nhóm tình báo an ninh của Altassian

Công việc của nhóm tình báo an ninh tại Atlassian là hack hệ thống của Atlassian y hệt như những kẻ tấn công thật sự. Điểm khác biệt duy nhất là, thay vì bán dữ liệu đánh cắp được, họ trình bày chi tiết cách thức tấn công đã làm cho nhóm bảo mật và phát triển sản phẩm, nhằm mục đích thúc đẩy các cải tiến bảo vệ hệ thống.

Với nhiều dữ liệu và ứng dụng đang di chuyển vào đám mây mỗi ngày, bảo mật là mối quan tâm hàng đầu đối với người tiêu dùng và các công ty. Tuy nhiên, điều đó không có nghĩa là tất cả chúng ta đều trở thành chuyên gia trong một sớm một chiều. Bài viết này bao gồm những câu trả lời của đội tình báo an ninh của Atlassian về những tấn công phổ biến nhất được sử dụng để khai thác các sản phẩm SaaS và cách để ngăn chặn chúng.

API không có trong văn bản chính thức

“Một trong những công cụ tấn công chính là Kiểm tra phần tử (Inspect Element).”

Dù có một chút mỉa mai vì tính cách hài hước của Alex, rõ ràng là anh chỉ nửa đùa nửa thật về cách tấn công nay. Đúng vậy, nghĩa đen là tùy chọn menu mà bạn thấy khi nhấp chuột phải vào một trang web. Nó cho phép bạn truy cập các công cụ dành cho nhà phát triển để hiển thị các yêu cầu trang web đang thực hiện. Hay nói cách khác, kẻ tấn công có thể tìm kiếm các lệnh gọi đến thứ gì đó ngoài API công khai của trang web, có thể là API riêng tư hoặc API của bên thứ ba.

Đôi khi phản hồi từ những API khác đó sẽ bao gồm những thứ mà nó thật sự không nên gửi về, như thông tin của khách hàng hoặc thậm chí là địa chỉ email của tất cả người dùng trang web. Và như thể vẫn chưa đủ đáng sợ, các lỗi kiểm soát truy cập như thế này có thể biến thành thảm họa PR toàn diện nếu tên của các điểm cuối (endpoint) của API là những cái tên dễ đoán. Tất cả những gì hacker cần làm là thử một cái gì đó đơn giản như thêm /users/1 vào cuối URI. Nếu yêu cầu này trả về hồ sơ của người dùng, thì chỉ cần viết một tập lệnh đơn giản gọi users 2, 3, 4,… để nhận được tất cả hồ sơ người dùng.

Những API này có thể không được lập thành văn bản, nhưng điều đó không cung cấp nhiều khả năng bảo vệ như bạn nghĩ. Alex cảnh báo: “Các API riêng tư có nhiều khả năng chứa lỗi hơn. Chúng thay đổi liên tục, do đó, có nhiều cơ hội để các tấn công bảo mật xâm nhập hơn. Ngược lại, các API công khai ít bị tấn công hơn vì chúng có xu hướng bị giám sát chặt chẽ hơn.”

Lấy ví dụ, xem xét các yêu cầu API khi Alex khai thác một ứng dụng cho phép bạn tìm ra những người bạn trên Facebook của mình cũng sử dụng ứng dụng đó. Có thể nhà phát triển ứng dụng đồng ý rằng bạn được biết điều đó, nhưng cũng có thể không. “Thật sự không có bảo mật nào bị bỏ qua hay có bất kỳ vụ hack nào. Chỉ là nó vốn ở đó.”

Thông tin nhạy cảm trong mã nguồn của bạn

Nếu nhóm của Alex muốn hack ai đó theo một cách độc hại – trái ngược với hack nhân từ trong công việc hằng ngày của họ, họ sẽ tìm một repo trên Git và sàng lọc nó, tìm kiếm mật khẩu. Họ nói: “Đây là một phương pháp tấn công phổ biến vì có tỷ suất hoàn vốn cao như vậy.”

Các ứng dụng SaaS hầu như không bao giờ hoàn toàn đóng kín. Chúng cần có khả năng kết nối với các ứng dụng khác hoặc các phần khác trong mạng riêng của bạn theo thời gian. Nói cách khác, các nhà phát triển ứng dụng viết những đoạn mã nguồn cần có khả năng đăng nhập vào những thứ như tài khoản AWS hoặc cần một API token để có thể truy cập vào API bên ngoài.

Tuy nhiên, bạn sẽ lưu trữ API token ở đâu để mã nguồn có thể lấy chúng? Tất nhiên, câu trả lời đơn giản nhất là để nó bên trong mã nguồn của bạn. Hoặc, nếu một số đoạn mã nguồn cần truy cập nó, bạn có thể lưu trữ trong một file cấu hình và thêm nó vào thư mục mã nguồn.

“Vấn đề là, Git được xây dựng để cộng tác. Thông tin được lưu trữ trong kho Git chắc chắn sẽ xuất hiện trên Internet công cộng.” – Alex nói. Tất nhiên là hầu hết các nhóm phát triển chuyên nghiệp đều đặt repo của họ ở chế độ riêng tư, nhưng Git duy trì lịch sử về tất cả các thay đổi trong suốt vòng đời của repo. Vì vậy, nếu nó được công khai, một cách vô tình (hoặc cố ý) vào một thời điểm nào đó, thì toàn bộ lịch sử đó cũng trở thành công khai. Ngay cả khi bạn đã xóa một tệp từ nhiều năm trước, lịch sử repo vẫn sẽ tồn tại mãi mãi.

“Mọi người hoàn toàn có thể lục tìm trong lịch sử của repo và tìm kiếm những thứ được cho là bí mật. Và có một chương trình sẽ tự động hóa nó cho bạn. Giống như là, có một tập lệnh đơn giản, có sẵn và công khai. Bạn chỉ cần trỏ vào tài khoản GitHub của một ai đó. Nó sẽ tải xuống tất cả các repo của họ và tìm kiếm những thứ bí mật trong đó.”

Vậy một nhà phát triển có ý thức cao về an toàn cần phải làm gì? Đây là một nguy cơ của sự đơn giản hóa. Đừng đưa những bí mật vào trong mã nguồn của bạn, cũng đừng phức tạp hóa nó. “Thực tế, bảo mật đến từ những điều đơn giản. Các lỗ hổng đến từ những thứ phức tạp.”

Trong hầu hết mọi trường hợp, vector tấn công này có thể được ngăn chặn bằng cách cung cấp các khóa API và thông tin xác thực khác trong các biến môi trường để mã nguồn truy cập chúng thông qua các biến đó.

Giả mạo yêu cầu phía máy chủ bằng EC2

Được biết bằng cái tên viết tắt, SSRF (Server-side request forgery) là một lỗ hổng cho phép những kẻ tấn công lạm dụng các ứng dụng phía máy chủ bằng cách đánh lừa khiến chúng thực hiện các lệnh gọi đến hệ thống mà kẻ tấn công không có quyền truy cập. Bằng cách gửi yêu cầu thông qua một máy chủ đáng tin cậy, những kẻ tấn công có thể truy cập hoặc thao túng dữ liệu nhạy cảm như thông tin tài khoản hoặc lịch sử mua hàng của người dùng.

Các lỗ hổng SSRF thường bị tấn công bởi các tác nhân xấu nhất khi sử dụng các tham số chứa URL đầy đủ trong request, thứ có thể được thay đổi để chỉ đến mục tiêu nhất định bên trong hệ thống của bạn. Nếu đó là một máy chủ AWS EC2, mọi thứ có thể trở nên tồi tệ hơn nữa.

“Có một loại địa chỉ ma thuật dành riêng cho EC2. Nếu bạn truy cập địa chỉ IP kỳ diệu đó, nó sẽ cung cấp cho bạn siêu dữ liệu về đối tượng bạn đang truy cập.”, Alex giải thích. Điều này cho phép những kẻ tấn công lấy được siêu dữ liệu hoặc nhiều hơn nữa, bao gồm cả thông tin xác nhận bảo mật. “Một khi họ đã vào trong, về cơ bản họ có thể kiểm soát toàn bộ đối tượng EC2.”

Việc nhận biết được khi nào bạn bị tấn công SSRF thật sự khó khăn, trừ khi bạn đã đăng nhập đúng chỗ. AWS GuardDuty cung cấp một số cảnh báo tích hợp, nhưng điều quan trọng là cảnh báo này và các cảnh báo khác cần phải được bật trước khi cuộc tấn công xảy ra.

Việc xác định xem một cuộc tấn công SSRF đã được thực hiện hay chưa đòi hỏi một số biện pháp điều tra nghiêm túc (nếu nó có thể xác định được). Mặc dù không có giải pháp vững chắc duy nhất nào dành cho SSRF, Alex khuyên rằng nên tuân theo nguyên tắc ít đặc quyền nhất làm điểm khởi đầu. Nói cách khác, bằng cách chỉ cấp cho mỗi lớp ứng dụng của bạn quyền truy cập vào dữ liệu và tài nguyên mà nó thật sự cần, bạn có thể hạn chế thiệt hại do kẻ tấn công gây ra nếu chúng xâm phạm thành công hệ thống của bạn.

Ngoài ra còn có một số khuyến nghị khác từ các kỹ sư bảo mật của Altassian, bao gồm:

– Khi kết nối với các URI do người dùng cung cấp, hãy định cấu hình và sử dụng máy chủ proxy không có quyền truy cập vào mạng nội bộ của bạn.
– Nếu có thể, hãy thiết lập các quy tắc tường lửa ngăn ứng dụng công khai của bạn kết nối với các vị trí nội bộ.
– Cân nhắc định cấu hình tài khoản AWS của bạn để yêu cầu IMDSv2 – khó truy cập bằng SSRF hơn IMDSv1.
– Sử dụng công cụ phát hiện tìm kiếm các lỗ hổng dựa trên dịch vụ cụ thể và những lỗ hổng nằm trong ngăm xếp ứng dụng của bạn.

Trong những kỹ thuật tấn công nêu trên, một số đơn giản đến mức một người bình thường có thể sử dụng được, một số tuy phổ biến nhưng lại mang lại hiệu quả cao không tưởng. Con người có những thành kiến nhận thức, ngụy biện logic và những tư tưởng, tâm lý tương tự. Khi nói đến việc bảo vệ bản thân, chúng ta có xu hướng tập trung vào các kịch bản phức tạp và thường quên mất những điều hiển nhiên. Hằng năm đều có những câu chuyện về những người bị mất trộm dù đã lắp hệ thống chống trộm trong nhà, chỉ vì để cửa chính rộng mở. Đó là một lời nhắc nhở tốt, rằng không có một vector tấn công nào là quá rõ ràng.

Hãy luôn cảnh giác!

Nguồn: Atlassian Blog