NEO SECURITY CASE STUDY: LỖ HỔNG 4TB CỦA EY

Hành trình phát hiện lỗ hổng 4TB của EY

Từ một HEAD request đến cuộc gọi khẩn cấp với Big Four

4 TB
Dữ liệu lộ
5 phút
Đủ để mất hết
7 ngày
Khắc phục
Terminal showing 4TB SQL-server backup discovery
🔍
Bước 1: Phát hiện bất thường

Nhà nghiên cứu đang thực hiện mapping bề mặt tấn công thông qua passive data sources, đột nhiên phát hiện response bất thường.

💡 Làm thế nào để kiểm tra?
Sử dụng HEAD request để kiểm tra metadata file mà không cần download:
curl -I https://[target-url]
Nếu thấy Content-Length khổng lồ (TB) → cảnh báo ngay!
⚠️
Bước 2: Phản ứng đầu tiên

Response: 200 OK | Content-Length: 4TB

File có format .BAK - SQL Server backup file. Đây không phải một file, mà là cả data center!

🚨 Tại sao nghiêm trọng?
SQL Server .BAK chứa TẤT CẢ: schema, data, stored procedures, và quan trọng nhất - MỌI SECRETS được lưu trong database (API keys, tokens, passwords, credentials).
🔎
Bước 3: Xác minh ownership

Quy trình điều tra:

  • Google bucket name → tìm được merger documents (tiếng châu Âu)
  • Dịch qua DeepL → công ty được mua lại năm 2020
  • Chạy SOA DNS lookup để tìm authoritative server
  • Kết quả: ey.com - Ernst & Young (Big Four!)
💡 Cách kiểm tra ownership:
dig SOA [domain] +short
nslookup -type=SOA [domain]
🧪
Bước 4: Xác minh file type

Không thể download 4TB (đó là tội phạm!), nên chỉ lấy 1000 bytes đầu tiên để kiểm tra "magic bytes" - chữ ký điện tử của file.

💡 Magic Bytes là gì?
Mỗi file type có signature riêng ở đầu file:
  • PDF: %PDF-
  • ZIP: PK..
  • JPEG: FF D8 FF
  • SQL Backup: signature đặc trưng của SQL Server
curl [url] -r 0-999 | file -

Kết quả: Xác nhận SQL Server backup, không mã hóa!

⏱️
Bước 5: Nhớ lại case study kinh hoàng

Flashback: Fintech breach case

Một công ty fintech từng bị breach chỉ vì engineer set bucket ACL = public trong 5 phút để download dễ hơn.

⚡ Tốc độ của automated scanners:
  • Quét toàn bộ IPv4 space (4.3 tỷ địa chỉ) trong vài phút
  • Botnet từ IoT devices, routers, cloud instances
  • Traffic tăng 400% trong 5 phút bucket mở public
  • Công ty phá sản sau vụ breach
Window giữa "exposed" và "exfiltrated" tính bằng GIÂY!
🚨
Bước 6: Responsible disclosure

Dừng mọi investigation ngay lập tức. Mỗi giây trôi qua = nguy cơ cao hơn ai đó khác tìm thấy.

Thách thức: Không tìm thấy security@ email hay VDP (Vulnerability Disclosure Program). Là cuối tuần!

📞 Quy trình báo cáo:
  • Tìm kiếm security contact → Không có
  • Cold-message 15 người qua LinkedIn
  • Cuối cùng tìm được người hiểu và connect với CSIRT
  • Thời gian: vài giờ (quá lâu cho incident này!)
✅
Bước 7: Response từ EY

Phản ứng chuyên nghiệp từ EY Security Team:

  • ✓ Acknowledgment ngay lập tức
  • ✓ Không có legal threats hay defensiveness
  • ✓ Giao tiếp kỹ thuật rõ ràng (engineer to engineer)
  • ✓ Không có corporate jargon
🎯 Kết quả:
7 ngày sau: Issue được triage và remediate hoàn toàn!
Đây là mô hình response lý tưởng mà các tổ chức nên học hỏi.
💭
Bước 8: Bài học rút ra

Nếu EY (với đầy đủ resources, security teams, compliance frameworks, ISO certifications) vẫn có thể mắc lỗi này → BẤT KỲ AI cũng có thể.

🎯 Nguyên nhân gốc rễ:
  • Cloud quá phức tạp, thay đổi quá nhanh
  • Infrastructure as Code → mistakes at scale
  • Dễ dàng export database với vài click
  • Một typo trong bucket name = disaster
  • Default settings không an toàn
⚠️ Quote quan trọng:
"You cannot defend what you do not know you own. You need the same continuous, automated, adversarial visibility that the attackers have."
🛡️ BẮT ĐẦU CHINH PHỤC CISA HÔM NAY

[ Nhanh hơn đối thủ cạnh tranh của bạn ]

Tìm hiểu thêm về Lớp CISA Online
Học CISA Online 🇻🇳

Nhận xét

Đăng nhận xét