1. Nguyên nhân ra đời bài viết
Dạo quanh một số nhóm chat IT mình có bắt gắp 1 case study trong 1 team có share service account và api key để tiện cho việc xây dựng ứng dụng. Không may có 1 bạn intern vô tình đẩy bộ code đó lên trên Github và để ở chế dộ public. Hacker dò được và truy cập trái phép vào tài khoản Google Cloud để tạo ra hàng loạt máy chủ với card GPU để đào coin.
Ae trong nhóm nội bộ trao đổi sôi nổi ôn lại kỉ niệm xưa vì case study này bản thân nhóm đã mắc lỗi tương tự cách đây 4 năm về trước. Bài viết ra đời nhằm ôn lại kiến thức cũng như chia sẻ một góc nhìn cho mọi người. Hy vọng bài viết nhận được các góp ý để nhóm tác giả hoàn thiện.
2. Bối cảnh lịch sử
Quay lại khoảng thời gian vào 4 năm về trước, vào những tháng cuối năm 2020, Team vận hành Cloud của công ty gồm 4 người chia làm 2 nhóm, tất cả đang trong giải đoạn nghiên cứu và học tập Cloud (2 người trong Nam và 2 người ngoài Bắc) có nhiệm vụ triển khai một số ứng dụng mới trên nền tảng Google Cloud, Ứng dụng cần sử dụng triển khai CI/CD và gọi một số API của Google. Theo sách giáo khoa thì Github và service account là nhưng lựa chọn lý tưởng và câu chuyện bắt đầu từ đây
3. Diễn biến sự kiện
Vào 1 buổi chiều đông, mình đặt phòng họp 3 tiếng để chuẩn bị thi chứng chỉ, mọi thứ diễn ra theo đúng kế hoạch và mình tạch, ra thì cu em intern với ánh mắt trìu mến hỏi thăm
Intern: anh có thì đỗ không
Ông anh thi trượt: với vẻ mặt như bị crush từ chối, trượt rồi
Intern: anh có muốn nghe thêm 1 tin buồn nữa không anh mặc dù em biết anh đang buồn
Ông anh thi trượt: Còn gì buồn hơn thì m nói nốt ra đi xem nào
Intern: Hệ thống bị hack anh ạ
Ông anh thi trượt: Đù, hack lúc nào sao giờ mới báo
Intern: Hack lúc anh đang thi nên không tiện báo =))
=> Ok họp team gấp
Trong cuộc họp, rất may trong lúc mình vắng đi thi thì có ông anh trong miền Nam đã nhận được cảnh báo của hệ thống qua email nên đã kịp thời vào khắc phục. Nguyên nhân cũng phát sinh từ việc ông em intern đã đẩy cả bộ code chứa key đã được cấp kèm theo cả service account lên trên Github để test. Dự án này thuộc dự án nghiên cứu nội bộ và môi trường độc lập với môi trường prod
4.Phương án khắc phục
Sau khi nhận cảnh báo thì người anh vào check tận gần 200 vm có GPU nên đã quyết định ngắt billing để giảm thiểu thiệt hại nhanh nhất. Đây là môi trường test nên việc ngắt billing là chuyện nên làm. Tuy nhiên nếu là môi trường prod sẽ rất phiền nên việc phân quyền và tách nhiều môi trường là cực kỳ quan trọng. Các bước bao gồm: xóa toàn bộ các VM do hacker tạo ra + xóa toàn bộ các service account + API key đã tạo trước đó. Ngắt billing ra khỏi project đó và liên hệ với support của Google Cloud để nhận được sự hỗ trợ. Mặc dù chỉ có hơn chục phút ít ỏi nhưng nhóm tấn công đã dựng rất nhiều các VM có GPU để đào coin (nhớ hồi đó người người đào coin nhà nhà đào coin nên việc tấn công chủ yếu là tạo VM để đào coin). Tổng thiệt hại là project mất toàn bộ lượng credit khoảng 4k$ chỉ trong vòng khoảng 30 phút ít ỏi.
Để cho mọi người dễ hình dung thì mình sẽ tính như sau:
Thường Hacker sẽ cố gắng tạo nhiều VM có GPU gắn nhiều nhất có thể tại tất cả các region mà chúng có thể tạo được. Lấy trung bình theo bảng giá trên là 2.48$ trên GPU trên 1 giờ, giả định tạo được 50 VM sử dụng card NVIDIA V100 8GPU
50*2.48*8=992$ / 1 tiếng
Tính toán trên chưa bao gồm CPU và RAM của 1 VM, chưa bao gồm các chi phí ổ đĩa, băng thông, số lượng máy chủ và loại card được tạo sẽ khác nhau, và một đặc điểm kẻ tấn công sẽ dùng IaC để tạo ra hàng loạt VM chứ không tạo bằng tay đâu nên con số trên sẽ tăng 1 cách chóng mặt.
5.Bài học rút ra
- Trong quá trình theo dõi việc tạo ra các budget alerts là vô cùng cần thiết và nên tạo ngay sau khi tạo mỗi project.
- Dù bất cứ môi trường nào, bao nhiêu project thì việc phân quyền tối thiểu là vô cùng quan trọng
- Nên tạo gửi cảnh báo cho càng nhiều người trong team càng tốt vì trong trường hợp trên mình đang không online (Thường mình sẽ setup gửi cho tất cả những người có trong dự án từ PM cho đến các Dev)
- Không nên chỉ tạo ra mỗi 1 kênh thông báo là email vì trong rất nhiều trường hợp email bị miss hoặc người theo dõi không để ý. Nên có thêm các kênh giao tiếp nội bộ như zalo, slack, telegram ,...
- Phải luôn bình tĩnh trong quá trình xử lý sự cố tránh tình trạng đổ lỗi cho nhau nên cùng tập trung xử lý sự cố trước mắt rồi tính tới vấn đề lỗi do ai. Thật may mắn Lead trực tiếp đã rất tâm lý để ae kỹ thuật xử lý xong rồi mới họp báo cáo vấn đề rồi đưa ra giải pháp để tránh các tình trạng đáng tiếc xảy ra tiếp theo.
==========Khi phát hiện bị tấn công cần phải làm gì ?===============
Bước 1: Đổi mật khẩu tài khoản Owner
Bước 2: Ngắt quyền các tài khoản không phải là Owner trên Google Cloud
Bước 3: Ngắt quyền các tài khoản service account / xóa các API Key đang sử dụng
Bước 4: Xóa các tài nguyên đang được tạo sai mục đích
Bước 5: Ngắt billing ra khỏi project
Bước 6: Viết ticket cho Google Cloud support để nhận hỗ trợ
Bước 7: Đọc logging của toàn bộ hệ thống
Bước 8: Họp nội bộ cả team phân tích tình huống đưa ra phương hướng giải quyết
Bước 9: Liên hệ google cloud nhờ support đồng thời
Bước 10: Khôi phục lại các tài nguyên, quyền, billing cho project.
======Dưới đây là 1 số lưu ý gần như bắt buộc khi sử dụng Cloud=========
1.Google workspace/Cloud Identity
-Bản chất muốn sử dụng Google cloud thì sẽ phải sử dụng gmail để đăng nhập vào trong trang portal nên việc sử dụng Google workspace để quản lý tập trung là rất cần thiết.
-Không sử dụng gmail cá nhân để quản trị -> 1 số công ty đã chót sử dụng email của Microsoft hay dùng kiểu này
-Sử dụng Google workspace group để nhóm các tài khoản trong cùng 1 phòng ban để dễ dàng quản lý thêm xóa thành viên cũng như áp dụng các chính sách bảo mật từ trên xuống
-Luôn bật MFA cho tất cả tài khoản trong org. Áp dụng chính sách từ Google workspace
-Luôn có 2 tài khoản Admin ở trên cả Google workspace và Google Cloud để dự phòng 1 người bị hack chiếm quyền
2.Bật MFA đối với tất cả các tài khoản
Nhắc lại 1 lần nữa ** Luôn bật MFA đối với tất cả các tài khoản **
3.Phân quyền IAM
-Áp dụng nguyên tắc phân quyền tối thiểu. Không được phân quyền Owner quá 3 tài khoản ngay cả khi trên môi trường test
-Cẩn thận sử dụng service account -> Hạn chế các quyền như Owner, Create VM -> vì đã có rất nhiều hacker tấn công từ đây
Case 1: Lập trình viên test ứng dụng để thông tin service account trong code và đẩy lên Github public -> Hacker quét thông tin github lấy được service account tạo ra hàng loạt các VM gắn card đồ họa NVIDIA đào coin
Case 2: Để Service account trong code -> Hacker tạo ra các VM tại nhiều region để đốt tiền nạn nhân
Case 3: Service account mất -> Hacker tạo 1 script chạy là có thể tạo rất nhiều tài nguyên làm phát sinh chi phí
4.Firewall
-Không bao giờ được mở 0.0.0.0/0 -> Môi trường test mở xong test phải đóng lại ngay lập tức
-SSH qua port 22 chỉ để địa chỉ IP của công ty mới có thể truy cập SSH
-Bật log trong VPC để ghi lại xử lý trên Google Cloud
5.Thiết lập ngưỡng cảnh báo trên Billing
Bắt buộc phải có ngưỡng cảnh báo để nhận thông tin khi có phát sinh chi phí hơn các tháng khác
6.Bảo mật nâng cao
Sử dụng VPN
Sử dụng VPN để đảm bảo mật từ client lên trên server (trừ trường hợp khách hàng không có hạ tầng đáp ứng)
Thiết lập 2 đường VPN để đảm bảo khi có sự cố xảy ra.
*Sử dụng key mã hóa *
Đối với các môi trường như ngân hàng, tài chính, kế toán -> Tìm hiểu thêm các case để sử dụng mã hóa file. Khá phức tạp trong việc đọc mở nhưng cần thiết.
Sử dụng các tool để masking dữ liệu ngay trong bản và quá trình truyền dữ liệu như Cloud Data Loss Prevention
Các cơ sở dữ liệu trên Google Cloud đều có các giải pháp mã hóa dữ liệu -> tùy thuộc môi trường, doanh nghiệp, nghiệp vụ có thể sử dụng
Sử dụng API
Sử dụng các API của Google cần bảo mật key/token cẩn thận
Tự code API -> phải có giải pháp để bảo vệ API của mình, có thể sử dụng Google APIgee, WSO2, Kong
*Lên lịch audit định kỳ *
Phải có kế hoạch audit định kỳ đối với các project trong ORG. Nghiêm túc thực hiện ngay cả đó là project test/dev
*Sử dụng các dịch vụ nâng cao đến từ Google để cấu hình *
Security Command Center → Check các lỗ hổng bảo mật
Cloud Key Management → Ứng dụng mã hóa dữ liệu
Chronicle Security Operations suite
BeyondCorp Enterprise
VPC Service Controls → Dùng để kiểm soát truy cập tới tất cả dịch vụ Google cloud
Chi tiết tham khảo Link: https://cloud.google.com/security
Chi tiết tham khảo thêm tài liệu từ GDG Cloud Hanoi
Tham khảo thêm các bài viết từ:
https://medium.com/@dangduchuygdg
https://cloudnewway.blogspot.com/
Top comments (0)