Tìm hiểu sâu hơn về sự cố bảo mật tháng 5 năm 2019: phản hồi về bài đăng trên blog
Chúng tôi vừa đăng bản cập nhật cho sự cố bảo mật xảy ra vào tháng 5 năm 2019 với các chi tiết kỹ thuật về những gì đã xảy ra, cách nó xảy ra và các biện pháp khắc phục mà chúng tôi đã áp dụng để ngăn sự cố tương tự xảy ra lần nữa. Dưới đây là một số đoạn trích từ bài đăng - đầu tiên là từ phần giới thiệu:
Vào khoảng 00:00 UTC vào ngày 12 tháng 5 năm 2019, chúng tôi đã được nhiều thành viên trong cộng đồng cảnh báo về sự leo thang đặc quyền không mong muốn đối với tài khoản người dùng mới. Một người dùng mà không ai nhận ra đã có được quyền truy cập cấp người kiểm duyệt và nhà phát triển trên tất cả các trang web trong Mạng Stack Exchange. Phản ứng ngay lập tức của chúng tôi là thu hồi các đặc quyền và tạm ngưng tài khoản này, sau đó thiết lập một quy trình để xác định và kiểm tra các hành động dẫn đến sự kiện.
Sau phát hiện ban đầu, chúng tôi nhận thấy rằng sự gia tăng đặc quyền chỉ là phần nổi của tảng băng chìm và cuộc tấn công đã thực sự dẫn đến việc đánh cắp mã nguồn của chúng tôi và vô tình làm lộ PII (email, tên thật, địa chỉ IP) của 184 người dùng của Mạng trao đổi ngăn xếp (tất cả đều đã được thông báo). Rất may, không có cơ sở dữ liệu nào — không công khai (đọc: nội dung của Stack Exchange) hay riêng tư (Nhóm, Nhân tài hoặc Doanh nghiệp) —được lọc. Ngoài ra, không có bằng chứng nào về bất kỳ quyền truy cập trực tiếp nào vào cơ sở hạ tầng mạng nội bộ của chúng tôi và chưa bao giờ kẻ tấn công có quyền truy cập vào dữ liệu trong các sản phẩm của Nhóm, Nhân tài hoặc Doanh nghiệp.
Và từ đoạn cuối cùng:
Sự cố này đã nhắc nhở chúng tôi về một số thực tiễn bảo mật cơ bản mà mọi người nên tuân theo:
- Ghi lại tất cả lưu lượng truy cập vào của bạn. Chúng tôi giữ nhật ký về tất cả các kết nối liên kết. Điều này cho phép tất cả các cuộc điều tra của chúng tôi. Bạn không thể điều tra những gì bạn không ghi nhật ký.
- Sử dụng 2FA. Hệ thống còn lại vẫn sử dụng xác thực cũ có thể là lỗ hổng lớn nhất của bạn.
- Bảo vệ bí mật tốt hơn. TeamCity có một cách để bảo vệ bí mật nhưng chúng tôi nhận thấy rằng chúng tôi đã không sử dụng nó một cách nhất quán. Hướng dẫn các kỹ sư rằng "bí mật không chỉ là mật khẩu". Bảo vệ khóa SSH và chuỗi kết nối cơ sở dữ liệu. Khi nghi ngờ, hãy bảo vệ nó. Nếu bạn phải lưu trữ bí mật trong kho lưu trữ Git, hãy bảo vệ chúng bằng git-crypt hoặc Blackbox .
- Xác thực yêu cầu của khách hàng. Yêu cầu từ khách hàng càng bất thường thì việc xác minh xem yêu cầu đó có hợp pháp hay không càng quan trọng.
- Thực hiện các báo cáo bảo mật một cách nghiêm túc. Chúng tôi rất biết ơn vì cộng đồng của chúng tôi đã báo cáo hoạt động đáng ngờ một cách nhanh chóng. Cảm ơn bạn!
Có rất nhiều điều khác trong bài đăng trên blog - vui lòng đặt bất kỳ câu hỏi hoặc nhận xét nào liên quan đến bài đăng bên dưới và chúng tôi sẽ cố gắng hết sức để trả lời chúng. Chúng tôi không thể bình luận về bất kỳ chi tiết nào khác liên quan đến cuộc tấn công ngoài những gì được đưa vào bài đăng trên blog, do các cuộc điều tra đang diễn ra.
Trả lời
Bạn có thể đưa ra bất kỳ nhận xét nào về ý định của những kẻ tấn công?
Có vẻ như họ đang theo đuổi một mục tiêu nhất định / dữ liệu (người dùng) nhất định không?
Hay có lẽ giống như một "thiếu niên tò mò" chọc gậy xem họ có thể đi được bao xa?
Tái bút cảm ơn vì sự cởi mở liên quan đến vấn đề này, nó thực sự được đánh giá cao!
Đường thẳng này:
Hành động tìm kiếm mọi thứ (truy cập câu hỏi) trên Mạng Stack Exchange trở nên thường xuyên và cho phép chúng tôi dự đoán và hiểu phương pháp luận của kẻ tấn công trong những ngày tới. (nhấn mạnh của tôi)
làm cho nó giống như trong thời gian thực , khi cuộc tấn công đang diễn ra, bạn có thể xác định kẻ tấn công sẽ làm gì dựa trên những gì chúng đã truy cập trên Stack Overflow, thay vì những gì chúng đã làm bằng cách nhìn vào những gì chúng đã xem (sau cuộc tấn công). Ý bạn là gì?
Một số câu hỏi chủ yếu liên quan đến kẻ tấn công:
- Điều gì đã xảy ra với kẻ tấn công?
- Bạn đã tạm ngưng tài khoản của họ?
- SE có liên lạc với kẻ tấn công bất cứ lúc nào không?
- Tại sao bạn không tiết lộ danh tính của kẻ tấn công?
- Có ai khác đã thử sử dụng cùng một phương pháp tấn công này sau đó không?
Có chu kỳ ngủ có thể phát hiện được ở đầu kia của các sự kiện không?
Chỉnh sửa để làm rõ:
Sau khi nhận biết được kẻ tấn công, và vì bạn đã theo dõi một số hành động của chúng khi chúng diễn ra, bạn có nhận thấy bất kỳ điều gì giống với một chu kỳ sinh học, cả ngày lẫn hồi không? Vd: Ăn (nghỉ 1-2 giờ), ngủ (8 giờ không hoạt động), "giấc ngủ ngắn" (90 phút), v.v.?
Đây không thực sự là một phần của sự cố, mà là mối quan tâm chung hơn về các biện pháp bảo mật xung quanh tài khoản của nhân viên. Có rất nhiều bước trong sự cố này, nhưng bước cuối cùng là nâng cấp đặc quyền của tài khoản SE. Tôi có thể hình dung ra nhiều cách đơn giản hơn để thực hiện điều này ngoài việc giành quyền truy cập quản trị vào máy chủ CI thông qua phiên bản dev để thực thi SQL trong phiên bản sản xuất và tôi quan tâm đến những biện pháp giảm thiểu và bảo mật mà SE đã thực hiện để bảo vệ khỏi những nỗ lực đơn giản hơn nhằm đạt truy cập vào tài khoản nhân viên.
Bạn không thể đặt các trang SE chính phía sau tường lửa, vì vậy chúng sẽ luôn bị lộ. Và phương thức đăng nhập nội bộ SE không cung cấp bất kỳ phương thức 2FA nào, điều mà tôi thấy hơi lo ngại.
- tài khoản nhân viên 2FA có được bảo vệ thông qua các phương tiện khác (hoặc các nhà cung cấp dịch vụ đăng nhập khác) không?
- có biện pháp nào để đảm bảo rằng không có địa chỉ email cá nhân hoặc nhà cung cấp thông tin đăng nhập nào được đính kèm với tài khoản nhân viên có thể kém an toàn hơn và vẫn được sử dụng để nhận thư khôi phục nhằm giành quyền truy cập vào tài khoản không?
- có giám sát các nỗ lực đăng nhập từ các nguồn mới cho tài khoản nhân viên không?
- có các biện pháp bảo vệ bổ sung cho các công cụ nhân viên nguy hiểm trong trường hợp ai đó giành được quyền truy cập vào phiên đang chạy của tài khoản nhân viên (ví dụ: yêu cầu lại mật khẩu và / hoặc mã thông báo 2FA khi truy cập các công cụ quan trọng về bảo mật)
Một cái gì đó giống như lừa đảo trực tuyến có lẽ vẫn là một trong những cách mà ai đó có thể cố gắng truy cập vào tài khoản nhân viên.
Vào cùng thời điểm sự cố bảo mật này xảy ra, vài ngày sau, một số người dùng bắt đầu nhận thấy rằng tính năng Oneboxing trong trò chuyện trên Twitter không hoạt động nữa . Một nhân viên sau đó đã xác nhận vào tháng 2 năm sau rằng nó thực sự đã bị vô hiệu hóa có chủ ý do phải "đóng một số lỗ hổng" do hậu quả của sự cố bảo mật này.
Chúng tôi có thể nhận được lời giải thích đầy đủ về lý do tại sao tính năng oneboxing trên Twitter trong trò chuyện phải bị vô hiệu hóa do sự cố bảo mật này không? Bài đăng trên blog được xuất bản vào thời điểm đó nói rằng "các vectơ tiềm năng khác" đã bị đóng cửa sau đó và thông báo nhân viên vào tháng 2 năm 2020 mà tôi đã liên kết ở trên nói rằng tính năng oneboxing của Twitter "đã sử dụng một trong những khoảng trống mà chúng tôi đã đóng". Thứ đó là gì và nó đã tạo ra rủi ro bảo mật nào?
Cuối cùng, có cách nào để chức năng này có thể được triển khai lại một cách an toàn không? Vào tháng 8 năm 2020, một vài tháng sau thông báo của nhân viên ở trên, báo cáo lỗi được gửi vào thời điểm đó đã được đánh dấu trạng thái thiết kế bởi một nhân viên khác. Yêu cầu tính năng thay đổi thiết kế trở lại (theo cách an toàn) có được xem xét hay không, hay không thể làm như vậy nếu không mở vectơ tấn công?
Tôi sẽ gắn cờ rằng các loại thông số "mật khẩu" trong TeamCity không được coi là tất cả các loại thông số an toàn:
Giá trị mật khẩu được lưu trữ trong tệp cấu hình trong Thư mục dữ liệu TeamCity. Tùy thuộc vào Cài đặt mã hóa máy chủ, giá trị được xáo trộn hoặc mã hóa bằng khóa tùy chỉnh.
Giá trị nhật ký bản dựng được ẩn bằng một thuật toán tìm kiếm và thay thế đơn giản, vì vậy nếu bạn có một mật khẩu tầm thường là "123", tất cả các lần xuất hiện của "123" sẽ bị thay thế, có khả năng làm lộ mật khẩu. Đặt tham số thành kiểu mật khẩu không đảm bảo rằng không thể truy xuất giá trị thô. Bất kỳ quản trị viên dự án nào cũng có thể truy xuất nó và bất kỳ nhà phát triển nào có thể thay đổi tập lệnh xây dựng đều có thể viết mã độc hại để lấy mật khẩu.
Tại sao liên kết ma thuật trong dev có thể xem được đối với CM (có lẽ chỉ trong dev) lại là liên kết ma thuật thực sự?
Đây thực sự là một báo cáo sự cố tuyệt vời! Một trong những cuốn hay nhất mà tôi đã đọc.
Cảm ơn Stack đã công khai nó và Dean vì một bài viết tuyệt vời!
Tôi chỉ tò mò muốn biết một số điều:
- Quy mô của đội ứng phó sự cố là bao nhiêu?
- Có bất kỳ giao thức cụ thể nào được tuân theo trong quá trình điều tra không?
- Yếu tố chính nào đã tham gia để thu hút nhà cung cấp bảo mật bên ngoài? Những điểm được cân nhắc khi chọn nhà cung cấp cụ thể đó là gì?
- Bài học kinh nghiệm nào từ nhà cung cấp bảo mật bên ngoài? Quy trình đánh giá của họ có khác (hiệu quả / không hiệu quả) với quy trình đã được nhóm sử dụng không?
Bài viết cung cấp một cái nhìn sơ lược về toàn bộ kiến trúc của Stack và các quy trình phát triển. Một bài đọc chi tiết hơn sẽ hoặc liên kết nếu đã có một bài báo về nó sẽ rất tuyệt.
Trong "Lời khuyên cho người khác":
Ghi lại tất cả lưu lượng truy cập vào của bạn. Chúng tôi giữ nhật ký về tất cả các kết nối liên kết. Điều này cho phép tất cả các cuộc điều tra của chúng tôi. Bạn không thể điều tra những gì bạn không ghi nhật ký.
Làm thế nào một mạng bận rộn như Stack Exchange có thể ghi lại toàn bộ lưu lượng truy cập vào? Đây có phải là các mục nhập của máy chủ web nhật ký, hoặc các luồng IP, hoặc các phiên TCP đầy đủ không?
Tôi có thể ghi lại hầu hết các mục nhập và nỗ lực kết nối trên mạng nhỏ của mình, nhưng tôi không biết làm thế nào mà một mạng lớn như vậy thực hiện được.
Bạn có thể giải thích rõ hơn "thuộc tính có thể truy cập công khai" có nghĩa là gì trong phần trích dẫn dưới đây không?
chúng tôi có một cơ sở dữ liệu chứa nhật ký của tất cả lưu lượng truy cập vào các thuộc tính có thể truy cập công khai của chúng tôi