- Vào ngày 31 tháng 5 năm 2024, công ty đám mây Snowflake đã gặp phải một vụ rò rỉ dữ liệu quy mô lớn
- Hudson Rock xác nhận rằng hacker đã truy cập thông qua lây nhiễm infostealer
- Hacker đã bán dữ liệu của nhiều công ty lớn, bao gồm Ticketmaster và ngân hàng Santander, trên các diễn đàn tội phạm mạng nói tiếng Nga
Phương thức tấn công
- Hacker đã đăng nhập vào tài khoản ServiceNow của một nhân viên Snowflake bằng thông tin xác thực bị đánh cắp.
- Chúng vượt qua OKTA để tạo session token và đánh cắp một lượng lớn dữ liệu.
- Hacker tuyên bố khoảng 400 công ty đã bị ảnh hưởng.
Bằng chứng bổ sung
- Hacker đã chia sẻ với các nhà nghiên cứu của Hudson Rock một tệp CSV cho thấy quyền truy cập vào máy chủ Snowflake.
- Tệp này ghi lại hơn 2.000 instance khách hàng liên quan đến các máy chủ châu Âu của Snowflake.
Mục tiêu của hacker
- Hacker đòi Snowflake 20 triệu USD để lấy lại dữ liệu.
- Công ty không phản hồi.
Sự gia tăng của lây nhiễm infostealer
- Lây nhiễm infostealer đã tăng 6000% kể từ năm 2018, trở thành một vector tấn công ban đầu chủ yếu.
- Nó được dùng để thực hiện các cuộc tấn công mạng như ransomware, rò rỉ dữ liệu, chiếm đoạt tài khoản và hoạt động gián điệp doanh nghiệp.
Ý kiến của GN⁺
- Tầm quan trọng của an ninh mạng: Vụ việc này cho thấy doanh nghiệp cần chú trọng hơn đến an ninh mạng. Đặc biệt, việc quản lý thông tin xác thực của nhân viên là rất quan trọng.
- Mối đe dọa từ infostealer: Infostealer đang lan rộng rất nhanh và doanh nghiệp cần chuẩn bị biện pháp đối phó.
- Chiến lược ứng phó: Khi xảy ra sự cố hack, cần có chiến lược phản ứng nhanh và giảm thiểu thiệt hại. Phản ứng chậm của Snowflake đã khiến thiệt hại gia tăng.
- Đào tạo bảo mật: Cần tăng cường đào tạo bảo mật cho nhân viên để nâng cao nhận thức về quản lý thông tin xác thực và các cuộc tấn công phishing.
- Giải pháp thay thế: Có thể cân nhắc các giải pháp lưu trữ đám mây khác cung cấp chức năng tương tự Snowflake. Ví dụ như AWS S3 hoặc Google Cloud Storage.
1 bình luận
Ý kiến trên Hacker News
Hiện tại URL được liên kết đang chuyển hướng 302 đến
/. @dang, có vẻ nên thay bằng liên kết lưu trữ bên dướihttps://web.archive.org/web/20240531140540/https://www.hudso...
Tuy vậy, việc Hudson Rock gỡ bài blog xuống cũng là một tín hiệu đáng chú ý, nên không thể просто đổi sang liên kết lưu trữ rồi bỏ qua. Đã có gì thay đổi?
Bổ sung: phản hồi chính thức của Snowflake dường như về cơ bản phủ nhận gần như toàn bộ các khẳng định cốt lõi trong bài viết gốc. Có thể Hudson Rock đã bị một nguồn tin không trung thực đánh lừa, rồi nhận ra sai sót và gỡ bài xuống
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Tôi là Felipe từ Snowflake. Quan điểm cập nhật nhất của Snowflake về vấn đề này ở đây: https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Nếu có thêm thông tin, tôi sẽ tiếp tục cập nhật URL này
Nhưng câu của Snowflake: “Tương tự như các tài khoản khách hàng bị ảnh hưởng, chúng tôi đã tìm thấy bằng chứng cho thấy tác nhân đe dọa đã lấy được thông tin xác thực cá nhân để truy cập một tài khoản demo thuộc sở hữu của một cựu nhân viên Snowflake. Không có dữ liệu nhạy cảm nào trong đó” khiến tôi hiểu rằng Snowflake xem mô tả của Hudson Rock là sai sự thật. Tôi hiểu vậy có đúng không?
Trong khi đó, bài của Snowflake lại có vẻ nói rằng thông tin xác thực tài khoản khách hàng bị lộ, và chỉ dừng ở đó, không có truy cập vào tài khoản trung tâm hay tài khoản khác. Cũng không nói gì về việc sử dụng thông tin tài khoản nhân viên không có xác thực hai yếu tố
Rõ ràng Snowflake sẽ muốn mọi thông tin xác thực truy cập nội bộ của nhân viên đều có xác thực hai yếu tố. Trước đây, nếu khách hàng muốn, họ có thể chỉ tạo tên người dùng/mật khẩu để đăng nhập vào dữ liệu của chính mình mà không cần xác thực hai yếu tố
Ảnh chụp màn hình nhật ký trò chuyện thực sự rất ấn tượng. Công ty này nói rằng họ đang liên lạc với một tội phạm thật sự, và tội phạm đó nói rằng nếu công ty này được sử dụng thì đã có thể giúp ngăn chặn vụ xâm phạm
Vì vậy tôi đã cập nhật đánh giá của mình về độ tin cậy của công ty này
Có vẻ Hudson Rock đã thuận theo và thổi phồng câu chuyện như thể đây là một vụ xâm phạm lớn hơn thực tế. Tôi cũng tò mò không biết hacker tìm đến Hudson Rock trước, hay Hudson Rock là công ty đầu tiên chịu tiếp chuyện
“Lẽ ra anh nên mua gói bảo vệ của Hudson Rock, như vậy đã có thể ngăn chuyện này”
“Đúng vậy, chắc chắn đã hữu ích”
“Chúc mừng. Công ty của bạn đã vượt qua một đợt kiểm toán an toàn thông tin bất ngờ và đã trở thành nạn nhân của ransomware.”
[...]
Các mục cung cấp: 1) hỗ trợ giải mã đầy đủ 2) bằng chứng xóa dữ liệu 3) báo cáo bảo mật về các lỗ hổng đã phát hiện 4) bảo đảm sẽ không công khai hoặc bán dữ liệu 5) bảo đảm sẽ không tấn công trong tương lai
Rốt cuộc chỉ là một công ty tư vấn bảo mật mà bạn không hề biết mình đã đưa vào bảng lương
Nhân tiện, tôi có xem họ đưa gì làm bằng chứng xóa dữ liệu, thì đúng nghĩa đen chỉ là đầu ra chuẩn của
rm -vrf data. Tôi hiểu rằng không thể đưa ra bằng chứng về sự không tồn tại và nạn nhân cũng không có đòn bẩy trong đàm phán, nhưng tôi khá thích màn diễn nàyKể cả là thật thì việc lược bỏ các tin nhắn của Hudson Rock mới là điều hợp lý. Tôi đã đưa công ty này vào danh sách đen trong đầu
Chỉ nhìn theo cách diễn đạt của thủ phạm thì có vẻ Snowflake đã thiết kế hệ thống theo kiểu trao toàn quyền cho mọi thứ chỉ bằng một tài khoản quản trị duy nhất
Việc Snowflake nói trong thông báo ngày 31 tháng 5 rằng họ đang điều tra “các cuộc tấn công dựa trên danh tính trên diện rộng trong toàn ngành đã ảnh hưởng đến một số khách hàng” cũng khiến câu chuyện về Ticketmaster và Santander thêm đáng tin
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Nếu tác nhân đe dọa đã làm đúng cách, đây có thể trở thành một trong những vụ rò rỉ dữ liệu lớn nhất từ trước đến nay
Dữ liệu dường như đến từ tài khoản Snowflake của người đó, vốn được dùng khi tạo bản demo cho khách hàng hoặc khách hàng tiềm năng. Có thể khách hàng đã cấp quyền truy cập để dùng một phần dữ liệu thực trong bản demo, nhưng điều đó còn rất xa với việc có quyền truy cập không giới hạn vào chính cơ sở dữ liệu Snowflake của khách hàng
Cũng hoàn toàn có khả năng hacker đã lấy dữ liệu giả dùng cho demo nhưng trông rất thuyết phục, rồi không biết được sự khác biệt
Một kỹ sư bán hàng phụ trách nhiều tài khoản. Kỹ sư bán hàng của Snowflake thường không xây dựng bên trong môi trường của khách hàng, mà thiết lập tài khoản demo tín dụng 400 USD mà ai cũng có thể tạo. Tài khoản demo sẽ hết hạn theo thời gian nên họ liên tục tạo mới
Kỹ sư bán hàng xây dựng trong các tài khoản demo họ tạo rồi trình diễn cho khách hàng. Sau 30 ngày, nếu không có thẻ tín dụng thì Snowflake sẽ khóa tài khoản, rồi sau đó xóa instance demo và dữ liệu
Để làm việc, khách hàng có thể chia sẻ dữ liệu từ instance Snowflake của họ sang instance demo do kỹ sư bán hàng tạo, hoặc cấp quyền truy cập cho kỹ sư bán hàng Snowflake đó thông qua SSO
Dù theo cách nào thì đây cũng gần như là vấn đề do các tổ chức đã không vận hành tư thế bảo mật đủ chặt chẽ. Đây không có gì mới ngoài việc họ đã tìm ra một kỹ sư bán hàng làm việc chăm chỉ, cùng những khách hàng không giới hạn đúng mức phạm vi quyền của nhân viên/nhà thầu/khách
Điều thú vị là ở trang đầu còn có một câu chuyện liền kề về việc Pegasus được dùng nhắm vào một NGO ở Đông Âu. Nguyên tắc đặc quyền tối thiểu rất quan trọng, nhưng bảo mật thiết bị cũng vậy
https://news.ycombinator.com/item?id=40535912
Tôi không phải nhân viên Snowflake, nhưng đã làm việc rất nhiều với Snowflake và tổ chức kỹ sư bán hàng của họ
Khi làm demo với khách hàng, các kỹ sư bán hàng sẽ tạo môi trường trình diễn bằng tài khoản demo Snowflake 400 USD mà ai cũng có thể tạo. Để làm demo, khách hàng cấp quyền truy cập cho kỹ sư bán hàng đó, và kỹ sư bán hàng sẽ mang một phần dữ liệu sang môi trường demo để thao tác. Tên môi trường mà Hudson Rock công bố cũng củng cố điều này
Theo tôi, đây là vấn đề quy trình: khách hàng đã không làm hết hạn ID của người từng chia sẻ dữ liệu, và tác nhân đe dọa đã đánh cắp thông tin xác thực. Đây không phải khai thác lỗ hổng nên không có gì mới
Và xin chúc mừng Hudson Rock vì đã công khai chỉ mặt một người bị hại do máy tính có malware. Chẳng khác gì cấp thông tin xác thực cho một nhà thầu rồi để chúng bị đánh cắp. Hành động rất bẩn
Snowflake biết rằng thông tin xác thực của kỹ sư bán hàng có thể bị đánh cắp, rằng các thông tin xác thực đó có thể vượt qua xác thực đa yếu tố, và theo bài báo thì cũng không hết hạn. Đó là strike 1, 2, 3
Các thực hành bảo mật của Snowflake đã tạo ra tình huống mà khách hàng bị yêu cầu hoặc ít nhất là bị khuyến khích chia sẻ quyền truy cập tới các bộ dữ liệu rộng cho nhân viên Snowflake. Đó là strike 4
Khách hàng có phần trách nhiệm vì đã cấp quyền quá rộng, nhưng Snowflake cũng có trách nhiệm vì đã không xây dựng một hệ thống tốt hơn để không cần kiểu truy cập này, hoặc ít nhất đã không giám sát và kiểm soát tốt hơn quyền truy cập mang tính bắc cầu đó
Một khi các tài khoản kiểu này được cấp quyền truy cập dữ liệu khách hàng, chúng không còn là “tài khoản demo” nữa. Chúng là tài khoản thật, và thực sự chứa dữ liệu rất có giá trị, nên phải được đối xử như vậy
Bổ sung: Snowflake nói rằng tài khoản demo nói trên không truy cập dữ liệu khách hàng và cũng không phải nguồn gốc vụ rò rỉ, điều này mâu thuẫn với tuyên bố của kẻ tấn công
“Hãy tưởng tượng bạn có quyền truy cập vào một nền tảng tìm kiếm khách hàng tiềm năng với hàng trăm nghìn công ty bị xâm phạm và các lỗ hổng đang hoạt động trên toàn thế giới, rồi có thể chuyển đổi họ thành khách hàng.”
Tôi đã thấy và từng làm việc với vài công ty kiểu này; chiến thuật khá hạ cấp và mức độ thành thạo hay công sức về kỹ thuật cũng thấp
Phản hồi chính thức của Snowflake viết như sau
“Chúng tôi cho rằng đây là kết quả của một cuộc tấn công dựa trên danh tính đang diễn ra trên toàn ngành, với mục đích lấy dữ liệu khách hàng. Theo điều tra, các cuộc tấn công này được thực hiện bằng thông tin xác thực người dùng của khách hàng đã bị lộ thông qua các hoạt động đe doạ mạng không liên quan. Cho đến nay, chúng tôi không cho rằng hoạt động này xảy ra do lỗ hổng trong sản phẩm Snowflake, lỗi cấu hình hay hành vi độc hại bên trong Snowflake.”
[0]https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Có vẻ họ đã chuyển bài viết sang chế độ riêng tư, nhưng trên Wayback Machine vẫn còn: https://web.archive.org/web/20240531140540/https://www.hudso...
Bài viết này cho rằng vụ xâm nhập Ticketmaster vài ngày trước thực ra là một vụ hack lớn hơn nhiều, ảnh hưởng đến hơn 400 công ty, thông qua thông tin xác thực bị đánh cắp của một nhân viên Snowflake
Hiện tại có vẻ đây là một câu chuyện lớn chỉ được đưa bởi hudsonrock.com. Tôi mới nghe đến Hudson Rock lần đầu, có ai biết đây có phải nguồn đáng tin không?
Nhiều tài khoản đã bị quản trị viên và admin Reddit cấm. Cá nhân tôi không xem đây là một nguồn đáng tin hay đáng tin cậy
https://www.bbc.co.uk/news/articles/c6ppv06e3n8o
Có vẻ Snowflake đang nói đây không phải lỗi của họ mà là lỗi của khách hàng
https://community.snowflake.com/s/question/0D5VI00000Emyl00A...
Nếu https://www.hudsonrock.com/blog/snowflake-massive-breach-acc... không hoàn toàn là bịa đặt thì Snowflake đang trình bày sự việc kém trung thực đi một chút
Cách diễn đạt “Theo điều tra…” mơ hồ, không rõ là điều tra nội bộ hay nghiên cứu bảo mật nói chung. Câu “không cho rằng là do lỗ hổng trong sản phẩm Snowflake, lỗi cấu hình hay hành vi độc hại bên trong Snowflake” cũng khéo léo liệt kê các kịch bản có thể có để phủ nhận, trong khi lại bỏ qua việc thực sự nó đã xảy ra như thế nào
Nếu tin Hudson Rock, Snowflake đã được tác nhân xấu liên hệ, nên rất có thể họ đã biết khá rõ chuyện này xảy ra thế nào
Họ nói là “được thực hiện bằng thông tin xác thực người dùng của khách hàng đã bị lộ thông qua các hoạt động đe doạ mạng không liên quan”, nên nếu không phải bịa thì có vẻ là thông tin xác thực đã bị lấy ở nơi khác
Cuối cùng họ còn bảo khách hàng rà soát cấu hình tài khoản, nên rõ ràng là đang đẩy trách nhiệm khỏi phía mình. Dù vậy, hiện tại nguồn tin gồm một công ty đã bị hack và một công ty đang tận dụng vụ này để quảng bá sản phẩm của mình đồng thời trơ trẽn công khai danh tính nhân viên, nên có lẽ phải chờ thêm thông tin chi tiết
Hacker còn nói họ thậm chí không làm hết hạn refresh token, nếu đúng thì đây là một vấn đề cực lớn và quá rõ ràng
Bài báo có vẻ không nhất quán lắm với tiêu đề “xâm nhập hàng trăm khách hàng”
Thứ nhất, mật khẩu lift/okta dường như chỉ cho phép truy cập cổng ServiceNow chứ không phải tài khoản khách hàng, nên vấn đề refresh token có vẻ chỉ giới hạn trong cổng ServiceNow và không liên quan đến việc lộ dữ liệu trong các tài khoản Snowflake thực tế của khách hàng
Thứ hai, ảnh chụp màn hình cho thấy 10 tài khoản công ty bị xâm nhập có 4 bộ thông tin xác thực tài khoản Snowflake khác nhau, trong đó một bộ trông giống tài khoản demo cá nhân. Vì vậy nhiều nhất cũng chỉ giải thích được khoảng 3 vụ xâm nhập khách hàng, nhưng không có chi tiết nào cho thấy các vụ xâm nhập khách hàng khác
Ngay cả nếu giả định mọi thông tin xác thực của mọi khách hàng mà kỹ sư bán hàng đó làm việc cùng đều đã bị xâm nhập, thì số khách hàng bị ảnh hưởng có lẽ cũng chỉ ở mức hai chữ số thấp. Vì mỗi tài khoản khách hàng phải cấp quyền truy cập riêng cho kỹ sư bán hàng đó
Dựa vào vấn đề refresh token của cổng Okta nội bộ để nói rằng toàn bộ khách hàng Snowflake đã bị xâm nhập là một bước nhảy vọt rất lớn, và vấn đề đó không gắn với bất kỳ tài khoản Snowflake nào của khách hàng