- Andrew Harris, cựu nhân viên Microsoft, cho biết sau khi phát hiện lỗ hổng Golden SAML trong AD FS vào năm 2016, ông đã yêu cầu xử lý trong nhiều năm, nhưng công ty không sửa ngay mà chỉ nhắc đến một phương án thay thế dài hạn
- Lỗ hổng này cho phép kẻ tấn công sau khi đánh cắp khóa riêng của máy chủ AD FS dùng token giả mạo để truy cập các dịch vụ đám mây như người dùng hợp lệ, để lại ít dấu vết trong nhật ký kiểm toán và có thể vượt qua cả xác thực đa yếu tố
- Đề xuất vô hiệu hóa seamless SSO của Harris xung đột với lo ngại về bất tiện cho khách hàng chính phủ liên bang, hợp đồng đám mây với Pentagon, cạnh tranh với Okta và suy giảm trải nghiệm người dùng
- Sau vụ tấn công SolarWinds năm 2020, tin tặc Nga đã lợi dụng điểm yếu này để thu thập dữ liệu nhạy cảm tại National Nuclear Security Administration, NIH, Treasury Department và các nơi khác; sau đó Microsoft khuyến nghị khách hàng Microsoft 365 vô hiệu hóa seamless SSO của AD FS
- Microsoft nói bảo vệ khách hàng là ưu tiên hàng đầu và các vấn đề bảo mật đã được xem xét nhiều lần, nhưng lời khai của cựu nhân viên cho thấy một trường hợp văn hóa bảo mật và ưu tiên kinh doanh va chạm với nhau
Lỗ hổng Golden SAML được phát hiện trong AD FS
- Andrew Harris từng làm việc tại Ghostbusters, một nhóm bí mật của Microsoft chuyên ứng phó các vụ hack nhắm vào khách hàng nhạy cảm; năm 2016, khi điều tra một vụ xâm nhập tại một công ty công nghệ lớn của Mỹ, ông tập trung vào vấn đề của AD FS
- AD FS là sản phẩm cho phép người dùng đăng nhập một lần để truy cập nhiều chương trình phục vụ công việc, và được hàng triệu người sử dụng
- Rủi ro cốt lõi mà Harris xác định là trong xác thực dựa trên SAML, kẻ tấn công có thể mạo danh nhân viên hợp pháp để truy cập các chương trình dựa trên đám mây
- Kẻ tấn công trước tiên xâm nhập máy chủ on-premises, rồi trích xuất khóa riêng từ máy chủ AD FS
- Sau đó chúng giả mạo token để trông như người dùng có đặc quyền cao
- Vì thông tin đăng nhập trông như bình thường, rất khó phát hiện bằng các nhật ký kiểm toán thông thường
- Harris cho rằng vấn đề này có thể ảnh hưởng không chỉ đến Microsoft Azure mà cả các tổ chức dùng nhà cung cấp đám mây khác như Amazon
“security boundary” và phán đoán của MSRC
- Harris đã báo vấn đề này cho Microsoft Security Response Center, tức MSRC, nhưng MSRC kết luận đây không phải là đối tượng cần sửa
- MSRC cho rằng vì kẻ tấn công trước hết phải truy cập máy chủ on-premises, điểm đó là ranh giới bảo mật, còn vấn đề chuyển tiếp lên đám mây sau đó không phải là một ranh giới bảo mật riêng
- Các cựu nhân viên MSRC nói rằng khi đó trung tâm phải xử lý nhiều báo cáo lỗ hổng trong tình trạng thiếu nhân lực, và tồn tại văn hóa kết luận “won’t fix”
- Họ nhớ lại rằng cụm từ “security boundary” lúc ấy chưa được định nghĩa rõ ràng và thường được Microsoft dùng như lý do để không sửa
- Bill Gates trong một bản ghi nhớ năm 2002 từng viết rằng khi phải chọn giữa thêm tính năng và giải quyết vấn đề bảo mật thì phải chọn bảo mật, nhưng các cựu nhân viên nói ảnh hưởng của MSRC đã yếu đi theo thời gian
Giải pháp tạm thời xung đột với logic kinh doanh
- Harris cho rằng việc sửa dài hạn có thể mất thời gian, nên đề xuất vô hiệu hóa seamless single sign-on(SSO) như một giải pháp tạm thời
- Tính năng này là tiện ích của Microsoft cho phép người dùng sau khi đăng nhập một lần có thể truy cập máy chủ on-premises và nhiều dịch vụ đám mây
- Theo Harris, người phụ trách sản phẩm Mark Morowczynski phản đối vì việc công khai lỗ hổng có thể gợi ý cho kẻ tấn công và gây bất tiện lớn cho khách hàng chính phủ liên bang
- Nhân viên chính phủ liên bang theo quy định phải đăng nhập bằng thẻ thông minh
- Harris giải thích rằng nếu tắt seamless SSO, khi truy cập đám mây sẽ cần đăng nhập lần thứ hai, và trong quá trình đó không thể dùng thẻ thông minh bắt buộc
- Hợp đồng đám mây lớn của Pentagon và cạnh tranh với Okta cũng được nêu là lý do phản đối
- Khi đó Microsoft đang cạnh tranh với Okta, và seamless SSO là một trong những lợi thế cạnh tranh của Microsoft
- Đề xuất của Harris tạo ra ma sát khi người dùng phải xác thực hai lần, xung đột với chiến lược sản phẩm
- Harris nhớ lại rằng Morowczynski nói quyết định này không phải quyết định kỹ thuật mà là quyết định kinh doanh
Cảnh báo từ các công ty bảo mật bên ngoài
- CyberArk năm 2017 công bố một bài blog gọi kỹ thuật này là Golden SAML cùng bằng chứng khái niệm
- Brad Smith sau đó trong câu trả lời bằng văn bản gửi Senate Intelligence Committee viết rằng Microsoft biết đến vấn đề này vào thời điểm CyberArk công bố năm 2017
- Lavi Lazarovitz của CyberArk cho biết trước khi công bố, vấn đề này đã được chia sẻ trong một nhóm chat WhatsApp kín có các nhà nghiên cứu bảo mật từ nhiều công ty tham gia, trong đó có cả nhà nghiên cứu của Microsoft
- Harris nói sau công bố của CyberArk, vấn đề trở nên khẩn cấp hơn nên ông lại nêu với nhóm sản phẩm và MSRC, nhưng MSRC vẫn giữ lập trường cũ
- Năm 2019, các nhà nghiên cứu Mandiant trình diễn tại một hội nghị ở Đức cách truy cập tài khoản và ứng dụng đám mây thông qua xâm nhập AD FS, đồng thời công bố cả công cụ
- Mandiant cho biết họ đã thông báo cho Microsoft trước khi trình bày
- Đây là trường hợp thứ hai trong khoảng 16 tháng một công ty bên ngoài thông báo cho Microsoft về vấn đề SAML
Cảnh báo khách hàng của Harris và trường hợp NYPD
- Năm 2019, Harris đăng một cảnh báo gián tiếp trên LinkedIn, đại ý rằng nếu có người quen chưa hiểu quan hệ xác thực AD FS thì hãy liên hệ
- Ông cố gắng trực tiếp thông báo rủi ro cho các khách hàng mà mình đã có quan hệ, một trong số đó là New York Police Department
- Harris giải thích điểm yếu AD FS cho Matthew Fraser, giám đốc IT của NYPD, và khuyến nghị vô hiệu hóa seamless SSO
- Fraser xác nhận cuộc họp đó và nói điểm yếu SAML đã được xác định là khu vực cần được bảo vệ và cô lập
- Harris rời Microsoft vào tháng 8/2020 để chuyển sang CrowdStrike, và nói rằng trong buổi phỏng vấn nghỉ việc ông cũng nêu lại điểm yếu SAML
Vượt qua xác thực đa yếu tố và vụ tấn công SolarWinds
- Harris nói rằng trong một cuộc trò chuyện với đồng nghiệp năm 2018, ông nhận ra kẻ tấn công có token giả mạo cũng có thể vượt qua xác thực đa yếu tố
- Vấn đề là ngay cả khi có thêm các bước bảo mật, kẻ tấn công vẫn có thể bỏ qua tất cả nếu có token giả mạo
- Cuối năm 2020, vụ tấn công SolarWinds được công bố, và chính phủ Mỹ cho biết các tin tặc được nhà nước Nga hậu thuẫn có liên quan
- Kẻ tấn công cài mã độc vào bản cập nhật phần mềm SolarWinds để có quyền truy cập cửa hậu vào mạng, rồi sau đó lợi dụng các lỗ hổng hậu xâm nhập như Golden SAML để đánh cắp dữ liệu đám mây và email
- Kẻ tấn công đã lợi dụng điểm yếu mà Harris chỉ ra để thu thập dữ liệu nhạy cảm của nhiều cơ quan
- National Nuclear Security Administration
- National Institutes of Health
- Nhiều tài khoản email của Treasury Department
- Brandon Wales của CISA khi đó nói gần một phần ba nạn nhân không dùng phần mềm SolarWinds
- Microsoft cũng bị xâm nhập, và ngay sau vụ tấn công, Microsoft khuyến nghị khách hàng Microsoft 365 tắt seamless SSO trong AD FS và các sản phẩm tương tự
Lập trường công khai và các biện pháp tiếp theo của Microsoft
- Microsoft President Brad Smith nói trước Quốc hội năm 2021 rằng không có lỗ hổng nào trong sản phẩm hoặc dịch vụ Microsoft bị khai thác trong vụ tấn công SolarWinds
- Smith giải thích Golden SAML được sử dụng trong 15% trong số 60 trường hợp Microsoft biết, đồng thời thừa nhận rằng những nạn nhân có dữ liệu bị quan sát hoặc đánh cắp không chỉ có chừng đó
- Smith nói nếu các tổ chức đã thực hiện nhiều biện pháp như mua sản phẩm antivirus Microsoft Defender và bảo vệ thiết bị bằng Intune, thiệt hại gần như đã không xảy ra
- Sau SolarWinds, Microsoft đã thực hiện các biện pháp nhằm giảm thiểu rủi ro SAML, và khả năng phát hiện hiệu quả hậu quả của vụ hack được đưa vào Sentinel, một sản phẩm bổ sung trả phí
- Microsoft trong blog gọi sự thiếu vắng khả năng phát hiện này là “blind spot”
Phản bác của Microsoft và tranh cãi về văn hóa bảo mật
- Microsoft không để Brad Smith và các lãnh đạo cấp cao khác trả lời phỏng vấn, nhưng cũng không phủ nhận các kết quả điều tra của ProPublica
- Trong trả lời bằng văn bản, công ty nói bảo vệ khách hàng luôn là ưu tiên hàng đầu, đội ứng phó bảo mật xử lý nghiêm túc mọi vấn đề và các vấn đề được đánh giá thủ công cũng như được đối tác kỹ thuật và bảo mật xem xét
- Microsoft giải thích rằng khi đánh giá mối đe dọa tiềm tàng, họ cân nhắc khả năng gián đoạn với khách hàng, khả năng bị khai thác và các biện pháp giảm thiểu sẵn có
- Vụ việc năm 2023, khi các tin tặc có liên hệ với chính phủ Trung Quốc khai thác lỗi bảo mật của Microsoft để truy cập email của quan chức cấp cao Mỹ, cũng trở thành đối tượng điều tra của House Homeland Security Committee
- Cyber Safety Review Board trong cuộc điều tra vụ việc này kết luận rằng văn hóa bảo mật của Microsoft là không phù hợp và cần cải tổ toàn diện
- Sau báo cáo của hội đồng, Satya Nadella nói với nhân viên rằng nếu bảo mật xung đột với các ưu tiên khác thì hãy chọn bảo mật
Cạnh tranh trong kinh doanh đám mây và kết quả
- Satya Nadella, người trở thành CEO năm 2014, đặt tương lai của Microsoft vào mảng đám mây Azure, trong khi lúc đó Azure tụt xa so với Amazon
- Microsoft đề xuất với khách hàng doanh nghiệp và chính phủ chiến lược đám mây lai, trong đó vẫn duy trì một phần máy chủ on-premises nhưng chuyển phần lớn điện toán lên đám mây
- Bảo mật là luận điểm cốt lõi trong bán hàng đám mây, với lợi thế được nêu là đội ngũ bảo mật chuyên trách sẽ xử lý bản vá và cập nhật
- Harris và các cựu nhân viên nói hợp đồng đám mây lớn của Pentagon cùng áp lực tăng trưởng Azure đã ảnh hưởng đến quyết định của đội sản phẩm
- Cuối cùng Microsoft cùng Amazon, Google và Oracle giành được một phần dự án đám mây kéo dài nhiều năm, trị giá hàng chục tỷ USD của Defense Department
- Sau khi SolarWinds được công bố, giá cổ phiếu Microsoft tăng 106%, với các lý do chính được nêu là thành công của Azure và các sản phẩm AI như ChatGPT
- Sản phẩm dài hạn thay thế AD FS mà Morowczynski được cho là đã nhắc với Harris năm 2017 bắt đầu được cung cấp vào năm 2022
1 bình luận
Ý kiến trên Hacker News
Giải pháp là áp dụng zero trust hoàn toàn trong tổ chức và không tin cậy mạng. Mạng nội bộ cũng phải được đối xử như bên ngoài, tức như một môi trường thù địch
Google là một trong những ví dụ đầu tiên triển khai rộng rãi zero trust với BeyondCorp, và có vẻ như sau Aurora thì không còn vụ xâm nhập nào vào tổ chức nội bộ của Google
Cần có endpoint được quản lý hoàn toàn, hardening endpoint mạnh, kiểm kê toàn bộ tài nguyên trong tổ chức, chứng chỉ theo từng thiết bị, và một engine danh sách kiểm soát truy cập để quyết định quyền truy cập tài nguyên theo từng người dùng
Cũng có thể phát hiện bất thường bằng các heuristic như giờ làm việc, và toàn bộ ứng dụng nội bộ của Google đều được đưa ra Internet rồi chuyển hướng về cổng SSO, nhưng thực tế thì không thể vào được. Phần lớn các vấn đề bảo mật kiểu này thực ra đã có lời giải, chỉ còn việc triển khai
Hầu hết các tổ chức lớn đã tích lũy công nghệ nội bộ lẫn bên ngoài suốt hàng chục năm, các hệ thống cũ gần như bị bỏ mặc, và do M&A cùng quyền tự do chọn công cụ theo từng bộ phận nên mức độ dị biệt rất lớn
Muốn chuyển sang zero trust thì cần một cuộc di trú quy mô lớn, “đào tạo” để thuyết phục đội ngũ IT bảo thủ, và chuyển sang mô hình tập trung kiểu Google
Hai việc đầu có thể còn xin được ngân sách, nhưng việc thứ ba có thể cực kỳ đắt đỏ. Một phần lý do Google bỏ đi nhiều thứ cũng là vì trong mô hình tập trung họ phải liên tục di trú và chấp nhận các bản nâng cấp có thể làm hỏng hệ thống
Trong startup, người ta muốn cung cấp cho khách hàng sự đồng nhất dựa trên các best practice như vậy, nhưng rồi đến lúc khách hàng có thể yêu cầu “hãy tắt zero trust đi và cho tôi dùng IP allowlist”. Vì một hợp đồng lớn, bạn có thể phải cân nhắc chấp nhận, và cũng không thể hủy một thương vụ thâu tóm chỉ vì công ty đó không có zero trust
Ngược lại, với đa số nơi đó gần như là một bài toán cực kỳ khó, và câu trả lời kiểu này nghe giống như “cứ vẽ hết cả con cú là xong”. Chỉ cần tưởng tượng Shaw Industries, hãng sản xuất thảm và vật liệu lát sàn lớn nhất nước Mỹ với 22.000 nhân viên, phải làm chuyện này là thấy
Nếu mang thái độ “an toàn tuyệt đối” thì bạn sẽ không còn tích cực đi tìm dấu hiệu xâm nhập nữa, và rồi sẽ bỏ lỡ vụ xâm nhập chắc chắn sẽ xảy ra vào một lúc nào đó
Zero trust là một triết lý, và là một triết lý khá tốt, nhưng bản thân nó không phải là lời giải. Nên xem nó là triết lý và thực hành tốt hơn là một đáp án tuyệt đối
Tôi không nghĩ kiến trúc này phù hợp với mọi công ty. Phần lớn các công ty công nghệ không thuần phần mềm bị thiệt hại bởi social engineering đơn giản, email lừa đảo, và việc chuyển giao thông tin xác thực cho bên thứ ba; gián điệp kinh tế cũng là một mối đe dọa lớn
Google có thể còn có những mối lo bảo mật khác như whistleblower hay các nhóm hoạt động xung đột với tầm nhìn của ban lãnh đạo, và với các vấn đề đó thì cấu trúc này có thể phù hợp. Nhưng điều đó không có nghĩa là vector đe dọa của mọi công ty đều giống nhau
Vấn đề bảo mật có thể giải được, nhưng hạ tầng cần thiết thì không hề nhỏ, và nhiều stack phần mềm kỹ thuật còn không hỗ trợ xác thực bên thứ ba
Các kỹ sư, kể cả khi không phải software developer, thường cũng không thích kiểu “endpoint được quản lý”. Google thì dùng được, nhưng đó gần như là một trường hợp đặc biệt; trong thực tế, phân đoạn mạng hợp lý có thể hiệu quả hơn nhiều
Lệch pha động cơ giữa bảo mật và lợi nhuận là thứ rất khó sửa, đặc biệt ở các công ty niêm yết, nếu không có thay đổi văn hóa cực lớn. Cũng không rõ điều gì có thể kích hoạt sự thay đổi đó
Tôi từng kiêm nhiệm an ninh mạng trong nhiều vai trò nhưng không theo hẳn nghề này vì những gì tận mắt thấy trong ngành. Người ta tập trung áp đảo vào compliance hơn là các thực hành bảo mật thực sự tốt, mà các tiêu chuẩn đó cũng còn thiếu hoặc bị thực thi yếu
Cần thay đổi văn hóa, nhưng tôi nghĩ nó phải đến từ phía khách hàng. Người tiêu dùng có thể khó làm được, nhưng nếu khách hàng doanh nghiệp đánh giá bảo mật nghiêm túc, yêu cầu các cam kết có tính ràng buộc, rồi ra quyết định mua sắm dựa trên đó, thì ngành sẽ phản ứng
Tất nhiên, Microsoft đã bám quá sâu vào thị trường desktop nên cách này khó mà phát huy hiệu quả trọn vẹn
Tuy vậy, đó cũng là phản ứng trực tiếp xuất phát từ việc thiếu một thay đổi văn hóa coi trọng bảo mật. Đội ngũ bảo mật thường chỉ có hai lựa chọn
Hoặc lên tiếng “bảo mật là quan trọng, hãy làm ra sản phẩm an toàn” rồi bị cười nhạo, hoặc vin vào compliance mà kiểm toán viên yêu cầu để ít nhất đẩy được mọi thứ tiến thêm một chút theo hướng bảo mật
Cá nhân cũng có lúc chọn tiền thay vì bảo mật. Chính phủ dường như cũng đã chọn lực lượng lao động năng suất hơn thay vì chi phí cao hơn và năng suất thấp hơn
Khi bán cho chính phủ, số tiền kiếm được và hiệu ứng quảng bá quá lớn nên sẽ tạo ra động cơ che giấu những sự thật khó chịu. Điều này gợi nhớ đến một nhà sản xuất máy bay cụ thể
Từ mức che giấu những nội dung hơi đáng xấu hổ cho đến gian lận khổng lồ, có hệ thống và có chủ đích, theo thời gian có thể lan ra toàn bộ phổ đó
Nếu lãnh đạo nói “hãy ưu tiên bảo mật/chất lượng” nhưng trên thực tế không thưởng cho điều đó thì bàn cờ coi như đã được bày sẵn
Nếu mỗi ngày đều thưởng hoặc phạt theo mục tiêu tiền bạc, còn khi thỉnh thoảng bị phát hiện thì chỉ phạt một hai cấp dưới, thì đối tượng mà công ty thực sự nghiêm túc không phải là bảo mật/chất lượng mà là tiền
Muốn đạt mục tiêu thì phải có động lực khuyến khích. Bộ phận bán hàng chịu áp lực lớn và có thể dễ bị sa thải, nhưng nếu thành công thì kiếm được rất nhiều tiền. Bảo mật thì dù thành công cũng chỉ là không bị sa thải, còn thất bại thì sẽ bị sa thải
Kết quả của công việc bảo mật tốt là “không có gì xảy ra”: không bị xâm nhập, không thảm họa, không náo động, nên cũng khó đo lường. Vấn đề là làm sao định lượng được sự vắng mặt của sự cố
Cuối cùng, bán hàng có rất nhiều củ cà rốt và cây gậy thì giống như mọi người khác, còn bảo mật thì không có củ cà rốt mà chỉ có cây gậy, thậm chí có thể là cây gậy gắn đầy đinh. Câu trả lời nằm ở văn hóa, và thay đổi văn hóa là điều khó nhất
Không nên mong bộ phận bán hàng phải lo về bảo mật; trọng tâm của bán hàng nên là tăng trưởng. Vấn đề là phía đối lập không được trao quyền và thẩm quyền để nói “không”, rằng bản sửa bảo mật phải được đưa vào trước tính năng mới
Nếu người quản lý dự án được thưởng theo tăng trưởng là người quyết định ưu tiên, thì dĩ nhiên họ sẽ chọn tăng trưởng thay vì bảo mật
Không phải đội bảo mật không biết vấn đề, mà là việc sửa lỗi không trở thành ưu tiên, còn văn hóa và quy trình thì không tạo được sự cân bằng giữa hai bên
Ở phía chính phủ cũng có động lực đáng kể để muốn hợp đồng được ký, ít nhất là với sự nghiệp của các cá nhân ra quyết định
Cả hai bên đều muốn thương vụ được chốt, và đều có động cơ che giấu khuyết điểm miễn là người dùng cuối không phát hiện ra trước khi họ nghỉ hưu
Tôi nghĩ mô hình ưu tiên bảo mật kiểu Microsoft, nơi Satya Nadella nói rằng “nếu phải chọn giữa bảo mật và các ưu tiên khác thì câu trả lời rất rõ ràng: hãy làm bảo mật”, là như thế này
Nhét quảng cáo vào khắp các ngóc ngách của Windows, cài một máy ghi hình ghi lại mọi việc người dùng làm, rồi gửi email cho nhân viên bảo “hãy làm bảo mật” là coi như hoàn thành nhiệm vụ
Chuyện đó khiến tôi cảm nhận rất rõ rằng phần lớn các khóa đào tạo, email và quy trình tồn tại để tạo khả năng chối bỏ có vẻ hợp lý
Ở Microsoft cũng có những người thật lòng quan tâm đến bảo mật. Tôi đã từng gặp trực tiếp. Nhưng nhìn chung, những cơ chế như vậy giúp Satya có thể nói trước tòa hoặc trước quốc hội rằng “chúng tôi đã bảo họ phải làm bảo mật tốt hơn. Đó là lỗi của đội sản phẩm hoặc của cá nhân đóng góp, chứ không phải do chính sách và động lực của Microsoft”
Câu chữ trong email không có trọng lượng gì cả. Khoảnh khắc lãnh đạo chọn đánh đổi bảo mật lấy một thứ khác, tín hiệu mà nhân viên cần nhận đã được truyền đi rồi
Tôi nhớ đến tranh cãi việc Canonical ghi lại tìm kiếm bằng phím Super và chuyện Ubuntu từng đưa quảng cáo Amazon vào mặc định
Người thích máy tính có thể cài Arch, Gentoo, NixOS Minimal rồi kiểm toán gói, nhưng kỳ vọng phần lớn những người không phải kỹ sư phần mềm cũng làm vậy là điều phi thực tế
Không chỉ Microsoft mà công ty nào cũng luôn có động lực gắn càng nhiều quảng cáo càng tốt và thu thập nhiều dữ liệu nhất có thể. Tôi không chắc mình có ủng hộ quy định hay không, nhưng cũng không biết còn cách nào khác
Như thường lệ, những câu sáo rỗng của giới điều hành kiểu “ưu tiên bảo mật” không quan trọng
Nếu vẫn thưởng và thăng chức cho người ta vì tính năng, trong khi không tưởng thưởng cho văn hóa bảo mật, thì con người và tầng lớp quản lý không hề ngốc, họ sẽ tối ưu theo hướng đó
Tôi không biết phải thiết kế các động lực này thế nào để giải quyết vấn đề, nhưng mọi thứ sẽ tiếp tục trôi theo kiểu này
Chừng nào người chịu trách nhiệm chưa bị trừng phạt và chưa có ai phải trả giá, thì có lẽ sẽ chẳng có gì xảy ra
Thông thường, tính năng được đưa vào sản phẩm khi marketing có thể chứng minh tính năng đó tạo tăng trưởng kinh doanh lớn hơn chi phí của nó. Có thể áp dụng cùng một ý tưởng
Kiểu như: “Lỗ hổng này ảnh hưởng đến X% khách hàng, khiến Y% rời đi và còn gây thiệt hại danh tiếng nên sẽ mất một khoản tiền lớn. Trong khi đó có thể sửa trong Z ngày với chi phí nhỏ. Quyết định thế nào?”
Tôi nghĩ đang có một manh mối khá lớn bị bỏ qua trong câu chuyện này. Nếu tắt seamless SSO thì sẽ có tác động rộng và rất đặc thù tới thẻ thông minh vật lý mà nhân viên chính phủ dùng khi đăng nhập vào thiết bị
Theo quy định liên bang, loại thẻ này là bắt buộc và tạo mật khẩu ngẫu nhiên mỗi lần đăng nhập, nhưng do cách công nghệ nền tảng được cấu hình, nếu bỏ seamless SSO thì người dùng sẽ không thể truy cập đám mây bằng thẻ thông minh
Chính phủ Mỹ là một trong những khách hàng lớn nhất của Microsoft, và quy mô cơ sở người dùng cùng Active Directory của họ cũng khổng lồ. Theo kinh nghiệm từng làm trong mảng này, quản lý người dùng và vai trò gần như là cơn ác mộng vì thông tin xác thực bị đánh cắp, tài khoản bị khóa, v.v., và luôn là mục tiêu tấn công
Chính phủ Mỹ đã cố chuyển tất cả mọi người sang xác thực bằng thẻ thông minh để giảm các vấn đề này, và nếu loại bỏ mật khẩu, chuyển toàn bộ sang xác thực hai yếu tố thì bề mặt tấn công sẽ giảm đi đáng kể
Thế nhưng người này về cơ bản lại muốn bảo Microsoft nói với khách hàng rằng cứ tắt nó đi như một phần của biện pháp khắc phục
Tôi không phủ nhận mức độ rủi ro của lỗ hổng SAML ban đầu, nhưng tôi nghĩ Harris đã đánh giá phần còn lại trong phản ứng của Microsoft một cách không công bằng. Điều ông ấy yêu cầu chẳng khác nào đề nghị tắt xác thực hai yếu tố trên toàn cơ quan
Biện pháp giảm thiểu ngắn hạn này gây tổn hại lớn cho bảo mật và có thể khiến khách hàng phơi lộ nhiều hơn trước đúng kiểu tấn công mà ban đầu họ muốn ngăn chặn. Câu chuyện này được đóng khung như một ví dụ khác về việc công ty không quan tâm đến bảo mật, nhưng có vẻ giống phản ứng từ một “người tố giác nội bộ” nhìn vấn đề quá hẹp trong tổng thể tư thế bảo mật của khách hàng
Đa số quản trị viên hệ thống an ninh thông tin ở các cơ quan chính phủ có lẽ cũng sẽ nói rằng đây không phải là một lựa chọn khả thi vì lý do đó
Suy cho cùng, đó cũng chính là ý của bài viết. Họ biết không có cách quản lý an toàn mà vẫn tiếp tục bán
Không phải để bênh Microsoft, nhưng tôi không chắc có thể chỉ ra được công ty nào thật sự ưu tiên bảo mật hơn lợi nhuận
Bill Gates từng nói vào năm 2002 rằng “nếu phải chọn giữa việc bổ sung tính năng và giải quyết vấn đề bảo mật thì nên chọn bảo mật”, và Satya Nadella cũng nói điều tương tự vào năm 2024 theo hướng “hãy làm bảo mật”
https://www.wired.com/2002/01/bill-gates-trustworthy-computi...
https://www.theverge.com/24148033/satya-nadella-microsoft-se...
Thực tế có những tính năng tôi dùng và sẵn sàng trả thêm tiền, nhưng họ không làm chỉ vì đó không phải giao thức an toàn hoàn toàn hoặc vì phải tích hợp với các ứng dụng lịch thông thường
Nếu khách hàng trả tiền không coi trọng bảo mật, thì nhà cung cấp cũng sẽ không coi trọng bảo mật, trừ khi có quy định hoặc yêu cầu pháp lý
Nhưng xét việc khách hàng của Microsoft gồm các tổ chức lớn và chính phủ, trường hợp này vẫn rất kỳ lạ. Có thể đã có sự ngạo mạn kiểu “chuyện đó sẽ không xảy ra với chúng ta” hoặc “sẽ chẳng ai biết đâu”
Giờ đây họ có lẽ đang thấy khả năng thiệt hại danh tiếng sẽ còn làm tổn hại cả lợi nhuận tương lai
Hãy tưởng tượng một nhà thầu xây một cây cầu lớn. Thanh tra an toàn nội bộ đã nhiều lần cảnh báo cấp trên về một khiếm khuyết kết cấu có thể dẫn đến sụp đổ, và theo thời gian bên ngoài cũng đã có hai cảnh báo công khai, nhưng công ty vẫn giảm nhẹ mức độ nghiêm trọng của vấn đề
Cuối cùng cây cầu sập, và sau đó lộ ra rằng công ty đã không làm gì vì không muốn mất các hợp đồng bán thêm nhiều cây cầu lỗi khác
Công chúng đương nhiên sẽ phẫn nộ, và những người liên quan sẽ phải đối mặt với hậu quả pháp lý. Nhưng tôi không hiểu điều gì khác biệt trong ngành của chúng ta mà khiến các công ty và nhà quản lý có thể thoát khỏi sự ác ý kiểu này
Có vẻ như trừ khi có đủ nhiều sinh mạng bị cướp đi, còn không thì người ta thường cũng chẳng quá bận tâm
https://www.nrk.no/innlandet/statens-vegvesen-legg-fram-rapp...
Phần mềm không ngay lập tức đe dọa tính mạng. Vì thế ngoài y tế và hàng không vũ trụ ra thì gần như mọi thứ vận hành như thời miền Viễn Tây
Việc dữ liệu cá nhân bị rò rỉ lên internet là kinh khủng, nhưng so với chuyện cửa máy bay bung ra thì ít ra vẫn còn thời gian để ứng phó
Chính phủ có thể bắt đầu tạo thay đổi bằng cách yêu cầu chữ ký và phê duyệt của cá nhân có giấy phép đối với các hợp đồng phần mềm bán cho chính phủ
Còn cáp treo Mottarone thì chắc chắn tương tự. Họ đã vận hành trong nhiều năm khi vô hiệu hóa thiết bị an toàn, và khi dây kéo bị đứt, cabin lao ngược xuống khiến toàn bộ hành khách thiệt mạng
Golden SAML không hẳn là một lỗ hổng; đúng như bài viết CyberArk được trích trong bài đã nhấn mạnh lại, đây là kiểu tấn công chỉ thực hiện được khi kẻ tấn công đã hoàn toàn chiếm được hệ thống trước đó.
Nếu tôi không hiểu nhầm điều gì, thì không thấy có lỗi cụ thể nào ở đây. Nói theo cách mỉa mai mà Microsoft bị chế giễu trong bài, đây không phải là việc vượt qua ranh giới bảo mật.
Với SSO thì lúc nào cũng có kiểu đánh đổi này. Nếu hạ tầng SSO bị xâm phạm, mọi thứ dùng nó đều có nguy cơ bị xâm phạm
Phần này bị lướt qua khá nhanh, nhưng tôi nghĩ “vụ hack” thực sự có lẽ chính là ở chỗ đó
Một khi đã dùng SSO thì việc giảm thiểu cũng không hề dễ. Một cách là để dịch vụ đích yêu cầu yếu tố thứ hai ngoài token SAML hợp lệ, nhưng như vậy mỗi người dùng sẽ phải duy trì yếu tố thứ hai luôn cập nhật cho từng dịch vụ đích riêng biệt.
Điều này nhanh chóng trở nên không thể quản lý, và trên thực tế cũng gần như không có SaaS hay ứng dụng tự lưu trữ nào vừa hỗ trợ SSO vừa hỗ trợ yếu tố thứ hai cùng lúc
Nó giống như tạo ra một kiểu tấn công tên là “GOLDEN ADMIN”. Nếu đã có thông tin xác thực quản trị viên thì bạn đăng nhập với tư cách quản trị viên và làm bất cứ điều gì mình muốn.
Tôi hiểu việc kẻ tấn công có thể xác thực ở bất cứ đâu mà không để lại log là điều tệ, nhưng tôi vẫn đồng ý với bình luận gốc
Tôi nghĩ vẫn có những cách khả thi
Đây không chỉ là vấn đề của Microsoft. Với tư cách là một kỹ sư bảo mật, nếu muốn vừa giữ được sự tỉnh táo vừa đạt thành tựu trong nghề này, bạn cần làm ở nơi có năng lực kỹ thuật, có động lực tuân thủ quy định mạnh cùng ngân sách, hoặc coi trọng bảo mật về mặt văn hóa vì mô hình đe dọa gắn chặt với lợi nhuận.
Theo tiêu chí của tôi, những ví dụ lớn phù hợp gồm các startup tiền IPO phải vượt qua SOC2 v.v. để lên sàn, ngành crypto nơi mô hình đe dọa như đánh cắp khóa và động lực lợi nhuận đều rất rõ ràng, và các công ty công nghệ đại chúng cung cấp nhiều hạ tầng cốt lõi.
Tuy vậy cũng có những nơi giống Microsoft, quá lớn đến mức khó mà sụp đổ, và cũng có những nơi như Google/Project Zero, Verizon/Paranoids, Cloudflare, nơi các đội bảo mật nội bộ trông có vẻ rất mạnh.
Ngân hàng có tiền, có văn hóa né tránh rủi ro và chịu quản lý chặt nên có thể ổn, nhưng y tế thì dù quy định mạnh tôi cũng tuyệt đối không muốn làm, vì số lượng tấn công quá nhiều và sự thờ ơ quá lớn.
Vì vậy, trừ khi bạn muốn vào đội DART để được thấy nhiều tác nhân đe dọa thực sự cùng nhiều ca ứng phó sự cố đa dạng, hoặc muốn làm bảo mật hệ điều hành ở mức rất thấp, còn không thì tôi không khuyến nghị làm kỹ sư bảo mật ở Microsoft.
Tôi không rõ công việc kỹ sư bảo mật ở Apple ra sao. Đây cũng là lý do thời gian bám trụ trung bình của một sự nghiệp trong ngành bảo mật chỉ vào khoảng 10 năm. Sự tỉnh táo dần bị bào mòn, còn đãi ngộ thì khá tốt nên đến tuổi 30–40 nhiều người có thể dùng số tiền tích lũy được để chuyển sang làm việc khác