Những người phòng thủ tư duy bằng danh sách, những kẻ tấn công tư duy bằng đồ thị (2015)
(github.com/JohnLaTwC)- Phòng thủ mạng thường bắt đầu từ việc liệt kê tài sản và sắp xếp ưu tiên, nhưng bề mặt tấn công thực tế lại được hình thành như một đồ thị phụ thuộc bảo mật giữa các tài sản
- Thay vì tấn công trực diện vào tài sản được bảo vệ mạnh nhất, kẻ tấn công tìm đường vòng tới tài sản giá trị cao thông qua các máy trạm hoặc đường quản trị được bảo vệ yếu hơn
- Trong mạng Windows, các yếu tố như kiểu đăng nhập, thông tin xác thực, Kerberos TGT, NTLM hash, mật khẩu quản trị viên cục bộ dùng chung, và script đăng nhập đều có thể trở thành các cạnh trong đồ thị
- Người phòng thủ cần biến danh sách tài sản thành đồ thị, rồi giảm tính kết nối bằng phân đoạn hạ tầng, silo thông tin xác thực, nguyên tắc đặc quyền tối thiểu, xác thực hai bước, và xoay vòng thông tin xác thực
- Kẻ tấn công không học từ sơ đồ cũ mà học dần hạ tầng thực tế từng mảnh một, nên người phòng thủ chỉ có thể giành lợi thế khi nắm chính xác hơn các mối liên kết trong mạng hiện tại
Những gì cách phòng thủ dựa trên danh sách bỏ lỡ
- Nhiều hoạt động phòng thủ mạng đã lệch hướng từ trước khi chạm trán kẻ tấn công, vì hiểu sai chiến trường
- Người phòng thủ tập trung vào việc bảo vệ tài sản, đặt mức ưu tiên, và sắp xếp theo khối lượng công việc cũng như chức năng kinh doanh
- Các dịch vụ quản trị hệ thống, cơ sở dữ liệu kiểm kê tài sản, và bảng tính BCDR đều tràn ngập danh sách tài sản
- Nhưng thứ người phòng thủ thực sự phải xử lý không phải là danh sách tài sản riêng lẻ, mà là một đồ thị trong đó các tài sản được nối với nhau bằng các quan hệ bảo mật
- Kẻ tấn công hạ cánh vào một điểm nào đó trên đồ thị bằng các kỹ thuật như spearphishing, rồi di chuyển trong mạng để tìm các hệ thống yếu
- Đồ thị này không phải thứ được cho sẵn từ bên ngoài, mà do chính người phòng thủ thiết kế và vận hành mạng tạo ra
Đồ thị bên trong mạng thực sự có ý nghĩa gì
- Đồ thị của mạng là tập hợp các phụ thuộc bảo mật tạo nên các lớp tương đương giữa các tài sản
- Có bốn nhóm yếu tố lớn ảnh hưởng tới đồ thị
- Thiết kế mạng
- Cách quản trị mạng
- Phần mềm và dịch vụ được dùng trong mạng
- Hành vi của người dùng
- Trong ví dụ về domain controller, chỉ một đường quản trị yếu cũng đủ kéo mức bảo mật của toàn bộ tài sản giá trị cao xuống thấp hơn
- Bob quản trị domain controller từ một máy trạm
- Nếu máy trạm đó không được bảo vệ ở mức tương đương domain controller, thì domain controller cũng có thể bị xâm nhập
- Các tài khoản khác có quyền quản trị trên máy trạm của Bob cũng có thể xâm nhập Bob và domain controller
- Những quản trị viên đó, do yêu cầu công việc, đăng nhập vào một hoặc nhiều máy khác
- Nếu kẻ tấn công xâm nhập được một trong số đó, chúng sẽ có đường đi tới domain controller
Six Degrees of Mallory: di chuyển ngang theo đồ thị
- Kẻ tấn công có thể nằm chờ trên máy đã xâm nhập và dùng công cụ trích xuất mật khẩu như mimikatz để chờ tài khoản giá trị cao đăng nhập
- Cụm bên trái trong đồ thị ví dụ là một Terminal Server duy nhất được hàng trăm người dùng sử dụng
- Nếu kẻ tấn công xâm nhập máy này, theo thời gian chúng có thể trích xuất thông tin xác thực của rất nhiều người dùng
- Tìm kiếm trên đồ thị cho thấy nhiều đường đi dẫn tới High Value Asset
- Việc xâm nhập Terminal Server cũng khiến User46 và User128 có thể bị xâm nhập
- User46 là quản trị viên của Machine2821, còn User128 là quản trị viên của Machine115
- Nếu xâm nhập các máy trạm đó, có thể xâm nhập tiếp User1 và User34
- User1 và User34 đều là quản trị viên của High Value Asset
- Muốn bảo vệ High Value Asset, mọi yếu tố mà nó phụ thuộc vào đều phải được bảo vệ nghiêm ngặt ở mức tương đương, và tất cả cùng tạo thành một lớp tương đương
Những quan hệ tạo ra phụ thuộc bảo mật
- Trong mạng Windows, khi người dùng thực hiện các kiểu đăng nhập nhất định như Interactive hoặc Terminal Server, nếu máy chủ nền bị xâm nhập thì thông tin xác thực của người dùng sẽ bị lộ trước nguy cơ bị đánh cắp
- Không chỉ thông tin xác thực mà cả các giá trị tương đương single sign-on như Kerberos TGT và NTLM hash cũng nằm trong diện phơi lộ
- Phụ thuộc bảo mật cũng được tạo ra trong các quan hệ quản trị thường nhật
- Tài khoản quản trị viên cục bộ dùng chung mật khẩu: sau khi trích xuất mật khẩu quản trị viên cục bộ trên một hệ thống, có thể dùng cùng mật khẩu đó trên các máy khác cũng dùng chung
- Máy chủ tệp chứa script đăng nhập chạy cho nhiều người dùng và máy chủ cập nhật phần mềm
- Máy chủ in truyền print driver xuống máy khách khi sử dụng
- Cơ quan cấp chứng chỉ phát hành chứng chỉ hợp lệ cho đăng nhập bằng smart card
- Quản trị viên cơ sở dữ liệu có thể thực thi mã trong ngữ cảnh máy chủ cơ sở dữ liệu chạy với người dùng đặc quyền
- Các quan hệ gián tiếp cũng là một phần của đồ thị
- Khi một máy có lỗ hổng bị xâm nhập, kẻ tấn công có thể tạo ra các cạnh mới trong đồ thị
- Nếu một người dùng có các tài khoản dùng cùng mật khẩu ở hai domain không có quan hệ tin cậy, một cạnh ẩn sẽ xuất hiện giữa hai domain
Cách phòng thủ để thu gọn đồ thị
- Bước đầu tiên của người phòng thủ là biến danh sách tài sản thành đồ thị để trực quan hóa mạng
- Sau đó cần cắt tỉa đồ thị bằng cách tìm các cạnh không mong muốn gây bùng nổ kết nối lớn
- Triển khai phân đoạn hạ tầng và silo thông tin xác thực
- Giảm số lượng quản trị viên và tối thiểu hóa đặc quyền bằng các kỹ thuật Just-In-Time / Just Enough
- Dùng xác thực hai bước để giảm thiểu việc di chuyển qua một số cạnh nhất định
- Áp dụng cơ chế xoay vòng thông tin xác thực vững chắc để chuẩn bị cho trường hợp tài khoản người dùng bị xâm nhập
- Rà soát lại các quan hệ forest trust
Xây dựng mô hình thực tế tốt hơn kẻ tấn công
- Người phòng thủ không nên nhường lợi thế cho kẻ tấn công khi trực quan hóa chiến trường
- Người phòng thủ có thể sở hữu thông tin tổng thể về mạng của mình, trong khi kẻ tấn công phải học dần mạng từng mảnh một
- Kẻ tấn công không nghiên cứu các mô hình tinh thần thiếu chính xác, hệ thống kiểm kê tài sản không đầy đủ hay sơ đồ mạng đã cũ, mà nghiên cứu hạ tầng đang tồn tại ở thời điểm hiện tại
- Người phòng thủ cũng phải quản trị mạng dựa trên thực tế như vậy thì mới tiến gần hơn đến tư duy của một người phòng thủ thực sự sẵn sàng
Đọc thêm
- Heat-ray: Combating Identity Snowball Attacks Using Machine Learning, Combinatorial Optimization and Attack Graph: J. Dunagan, D. Simon, A. Zheng
- Two Formal Analyses of Attack Graphs: S. Jha, O. Sheyner, J. Wing
- Using Model Checking to Analyze Network Vulnerabilities: P. Ammann, R. Ritchey
- A Graph-Based System for Network-Vulnerability Analysis: C. Phillips, L. Swiler
- Automated Generation and Analysis of Attack Graphs: J. Haines, S. Jha, R. Lippman, O. Sheyner, J. Wing
- Modern Intrusion Practices: Gerardo Richarte
- Attack Planning in the Real World: Jorge Lucangeli Obes, Gerardo Richarte, Carlos Sarraute
1 bình luận
Ý kiến trên Hacker News
Kẻ tấn công thường có một nhiệm vụ, chẳng hạn như rò rỉ dữ liệu quan trọng, làm bất ổn mục tiêu, hoặc ransomware, và có thể đào sâu đến mức cần thiết cho tới khi đạt được nhiệm vụ
Trong khi đó, người phòng thủ phải theo dõi đồng thời nhiều tín hiệu và vector đe dọa, nên buộc phải tư duy bằng danh sách, và còn phải ưu tiên cả những hạng mục cần xử lý vì quy định
Nếu không phải kiểu người phòng thủ được bố trí tùy ý ở khắp nơi trên đồ thị để tìm hoạt động đáng chú ý, tôi không rõ người phòng thủ có thể tư duy bằng đồ thị như thế nào. Những gì tác giả đề xuất rốt cuộc cũng chỉ trở thành các tín hiệu trong danh sách mà người phòng thủ phải đối chiếu
Khi người phòng thủ áp dụng cách đó, họ đã có thể nhận diện các cuộc tấn công tiềm tàng trước khi red team thực hiện. Những đội thông minh sẽ nhanh chóng tiếp nhận các kỹ thuật red team như crawl AWS dưới dạng đồ thị để tìm đường từ tài khoản giá trị thấp tới tài khoản giá trị cao
Đây không phải vấn đề zero-sum hay một cuộc chuyển đổi lớn, nhưng người phòng thủ cũng có thể tư duy giống kẻ tấn công nhiều hơn và dùng công cụ của kẻ tấn công cho phòng thủ thường xuyên hơn
Khi đó cần bảo vệ các đường đi dẫn tới mục tiêu đó, bất kể đường đi ấy trông như thế nào hay có bị giới hạn trong phần mềm hay không
Kẻ tấn công có thể khai thác CVE để khiến hệ thống giải trí rơi vào trạng thái từ chối dịch vụ, nhưng tôi nghi ngờ việc đó thực sự quan trọng đến mức nào
Phần lớn các cuộc tấn công thực tế gần với kiểu “đi xem có thể tìm thấy gì, rồi sau đó tính xem dùng nó thế nào”. Nhiều hoạt động tấn công như thu thập thông tin, chiến dịch gây ảnh hưởng, tuyên truyền cũng vậy
Lý do người phòng thủ dùng danh sách là vì họ phải quản lý đồng thời hàng trăm, hàng nghìn tài sản. Khi phải quản lý nhiều thứ, bạn sẽ lập danh sách, rà qua danh sách đó và áp dụng checklist
Tất nhiên người phòng thủ cũng nên tạo đồ thị phụ thuộc, nhưng trước hết phải lập danh sách, kiểm tra xem danh sách có được cập nhật không, có giả định mức tin cậy hạn chế không, tài nguyên có được cô lập không, rồi sau đó mới tạo đồ thị phụ thuộc
Người phòng thủ phải nghĩ cả bằng danh sách lẫn đồ thị và quản lý một số lượng hạng mục khổng lồ, còn kẻ tấn công chỉ cần nhìn vài thứ
Nếu không có insight để chuyển danh sách thành đồ thị, cuối cùng bạn chỉ cầm danh sách tài sản cốt lõi và chặn kiểu đập chuột chũi hàng chục nghìn đường tiếp cận mà mình chưa từng cân nhắc
Tôi có cảm giác bài này đi quá sâu. Hoặc có thể lý do thì đúng nhưng nguyên nhân thì sai. Công việc của người phòng thủ không phải là bản thân việc phòng thủ
An ninh mạng không phải một trận đấu thể thao có mục tiêu rõ ràng, ngang sức và các vị trí luân phiên, mà giống một sự kiện phụ bên cạnh hoạt động kinh doanh khác mà người phòng thủ thực sự muốn làm, và gần như là một thứ gây xao nhãng
Ngược lại, toàn bộ công việc của kẻ tấn công là tấn công hệ thống. Không có mục đích nào khác, ông chủ phụ nào khác, hay cân nhắc nào khác làm suy yếu cuộc tấn công
Lý do kẻ tấn công thắng cũng giống lý do Microsoft phát hành hệ điều hành giỏi hơn Cisco. Với Cisco, hệ điều hành là phương tiện; với Microsoft, đó là mục đích
Nó cũng giải thích vì sao doanh nghiệp gần như không bị thị trường trừng phạt vì rò rỉ dữ liệu
Các cuộc tấn công mạng có mục đích rõ ràng như đánh cắp dữ liệu, làm gián đoạn dịch vụ, v.v. Điều đó có thể đúng với các tác nhân non tay chỉ muốn phá hoại và tạo hỗn loạn, nhưng nếu xét tới tác nhân quốc gia hoặc tội phạm có động cơ tài chính thì quan điểm này hoàn toàn lệch
Tôi lại có cảm giác bài này chưa đi đủ sâu :-)
“Danh sách” là cách nói rút gọn cho các thành phần, còn “đồ thị” là cách nói rút gọn cho khả năng tương tác. Góc nhìn thành phần là phân tích; góc nhìn tương tác thì vẫn chưa có từ hay, nhưng như bài viết nói, nó thường trở thành bề mặt tấn công
Hệ thích nghi phức tạp có các thành phần và message bus, và điều quan trọng là bus này cung cấp cách để các thành phần tương tác với nhau. Bạn có thể bắt từng con kiến một, nhưng nếu thực sự muốn ngăn chặn, bạn phải loại bỏ khả năng để lại dấu vết pheromone
Giá mà cũng có một từ như “phân tích” để chỉ việc hiểu các cách tương tác. Kiểu như Gestaltysis chăng?
Tôi từng làm một thời gian ngắn ở một công ty an ninh mạng, nhưng khi đó không diễn đạt được vì sao mình ghét sản phẩm đó, và vì sao cách tiếp cận của công ty cũng như phần lớn ngành này rốt cuộc lại có cảm giác giả tạo
Giờ thì tôi hiểu rồi. Chúng tôi đang xây dựng công cụ hỗ trợ thực hành vô dụng nhất trong an ninh mạng: checklist ở cấp độ tổ chức
Ở trung tâm của mọi hoạt động đều là danh sách và lịch lặp lại. Phải xuất hiện định kỳ và làm những việc cần làm
Tất nhiên, tôi đồng ý rằng ở bước “những việc cần làm” đó cần một cách tiếp cận sâu hơn và tốt hơn
Để nói rằng: “Chúng tôi đã làm theo mọi checklist, phần mềm bảo mật không bắt được, nên không phải lỗi của chúng tôi”
Nếu công ty thật sự quan tâm đến bảo mật, họ sẽ thuê red team thay vì trả tiền cho những scanner vô dụng có tỷ lệ tín hiệu trên nhiễu dưới 1%
Nhìn sang hàng không, phi công sống nhờ checklist. Nó không bảo đảm rằng trong chuyến bay sẽ tuyệt đối không có vấn đề, nhưng không làm theo checklist hoặc xem nhẹ nó là mời gọi thảm họa. Những checklist như vậy được xây dựng trên nhiều năm kinh nghiệm đắt giá
Nhưng checklist chỉ tồn tại để có thể nói “chúng tôi có checklist”, hoặc không được rà soát và cập nhật định kỳ theo điều kiện thực tế, thì vô nghĩa
Nhiều công ty hiểu sai điều này. Họ nghĩ bản thân checklist là bảo mật, nhưng thực ra checklist chỉ là công cụ nhắc nhở tiếp tục duy trì những việc trước đây đã làm đúng. Ngay khoảnh khắc coi checklist như mục tiêu, bạn đã đi chệch hướng
Từ góc nhìn của một penetration tester, kẻ tấn công cũng không nhất thiết tư duy bằng đồ thị
Ngoài BloodHound, tôi không nghĩ ra công cụ nào dùng đồ thị
Trong bảo mật web tôi cũng không nghĩ ra trường hợp nào áp dụng “tư duy đồ thị”. Thay vào đó là một danh sách tấn công rất lớn để kiểm thử: https://portswigger.net/web-security/all-topics
Và thứ rốt cuộc đi vào báo cáo pentest không phải đồ thị mà là danh sách việc cần làm. Ví dụ như ký SMB, không dùng tài khoản domain admin để quản trị mọi máy, v.v.
Lý do chính câu này được ưa chuộng là vì nó vuốt ve cái tôi của cộng đồng hacker. Kiểu như “chúng ta là phe thông minh, còn bên phòng thủ chỉ biết nghịch bảng Excel”
Tuy nhiên cũng có một phần sự thật. Bên phòng thủ có thể tốn rất nhiều thời gian vào những việc không quá quan trọng. Chẳng hạn tự tay áp CIS benchmark cho mọi máy chủ, trong khi bỏ lỡ những trái cây treo thấp có thể tạo ra tư thế bảo mật mạnh
Ở nhiều công ty, người phòng thủ chỉ là quản trị viên hệ thống không biết nên tập trung vào đâu
Ví dụ hiện ra ngay là chuỗi lỗi. Ghép vài lỗ hổng mức CVSS 4–7 lại với nhau có thể biến thành kết quả cấp 9.8 như thực thi mã từ xa hoàn chỉnh. Việc liên kết các lỗi như vậy về bản chất là duyệt đồ thị qua các yếu tố xâm nhập
BloodHound rất tuyệt, và là công cụ trực quan tốt để khái niệm hóa đồ thị tấn công, nhưng nó chỉ là một phần trong quá trình hiểu domain mục tiêu từ góc nhìn của kẻ tấn công
Lý do pentest web không có công cụ gọn gàng như BloodHound là vì khó quy giản chuỗi xâm nhập đơn giản thành dạng công cụ. AD có các ranh giới bảo mật ở mức nào đó đã được hiểu và mã hóa, còn các chuỗi trong web app thường đặc thù theo ứng dụng đó hơn là theo framework nền
Những mục như ký SMB hay “đừng quản lý tất cả bằng tài khoản DA” xuất hiện trong báo cáo pentest vì chúng là các nút phát sáng rất mạnh ở giai đoạn rất sớm của chuỗi xâm nhập. Ngoài đời, hệ thống thường bị hạ theo cách đó
Không hẳn vì pentester không hiểu tư duy đồ thị, mà gần hơn là vì nút đầu tiên của đồ thị trên thực tế đã đồng nghĩa với xâm nhập hoàn toàn, nên không còn lý do để duyệt tiếp
Câu này gần như chỉ là cách nói hoa mỹ hơn của việc bên phòng thủ phải bảo vệ mọi điểm vào, còn kẻ tấn công chỉ cần tìm một điểm yếu
Ví dụ, liệu có thể dùng honeypot để đẩy ngược khai thác zero-day về thiết bị của kẻ tấn công không. Có thể đó là thứ được cố ý thiết kế trong sản phẩm của Google, Microsoft, v.v.
Kiểu đi hẳn theo hướng blackhat với một mức phủ nhận hợp lý nào đó, như cho kẻ tấn công ransomware ăn chính ransomware
Viết đến đây nghe giống các tập đoàn toàn năng độc ác trong khoa học viễn tưởng, mà những tập đoàn đó thường còn ám sát kẻ thù nữa
Tôi từng làm ứng phó sự cố, cũng có kinh nghiệm pentest và red team. Dù là cách diễn đạt rút gọn, tôi thấy nó đúng ở một mức nào đó, và không nhất thiết phải tiêu cực như bài viết nói
Phòng thủ gồm nhiều yếu tố. Ví dụ như phát triển các kiểm soát hiệu quả để giảm rủi ro và tác động của sự cố bảo mật, nhận diện tấn công và xâm nhập, cũng như ứng phó sự cố. Danh sách tiêu chuẩn và phản ứng hoạt động tốt
Phòng thủ cũng bao gồm các quyết định kiến trúc đòi hỏi phải nghĩ về đồ thị mạng để thiết kế những kiểm soát này. Lĩnh vực phòng thủ cũng đa dạng: kiến trúc/kỹ thuật, quản lý rủi ro, ứng phó sự cố, bảo mật ứng dụng, đào tạo, tình báo mối đe dọa, v.v.
Cũng thú vị là tác giả ám chỉ việc phòng thủ tư duy bằng danh sách là vấn đề, rồi lại đưa ra một danh sách các mục cần cân nhắc để cải thiện phòng thủ
Lý do kẻ tấn công thắng là vì sau khi tìm thấy điểm yếu, họ chỉ cần thành công một lần. Bên phòng thủ phải bảo vệ mọi thứ cùng lúc
Có vẻ mỗi mạng cần ít nhất một honeypot để bắt kẻ xâm nhập. Những thứ như thông tin xác thực tiền mã hóa giả, kho mật khẩu giả thuộc dạng này