Nếu một từ có thể tổng kết năm an ninh thông tin 2021 (tốt, thực tế là ba), thì đó sẽ là: “cuộc tấn công chuỗi cung ứng”.
Một cuộc tấn công chuỗi cung ứng phần mềm xảy ra khi tin tặc thao túng mã trong các thành phần phần mềm của bên thứ ba để xâm phạm các ứng dụng ‘hạ nguồn' sử dụng chúng. Vào năm 2021, chúng ta đã chứng kiến sự gia tăng đáng kể của các cuộc tấn công như vậy: các sự cố bảo mật cao cấp như vụ vi phạm dữ liệu SolarWinds, Kaseya và Codecov đã làm lung lay niềm tin của doanh nghiệp vào các hoạt động bảo mật của các nhà cung cấp dịch vụ bên thứ ba.
Bạn có thể hỏi điều này liên quan gì đến bí mật? Trong ngắn hạn, rất nhiều. Lấy trường hợp Codecov (chúng ta sẽ quay lại nhanh): đây là một ví dụ trong sách giáo khoa để minh họa cách tin tặc tận dụng thông tin đăng nhập được mã hóa cứng để có được quyền truy cập ban đầu vào hệ thống của nạn nhân và thu thập thêm bí mật trong chuỗi.
Secrets-in-code vẫn là một trong những lỗ hổng bị bỏ qua nhiều nhất trong không gian bảo mật ứng dụng, mặc dù là mục tiêu ưu tiên trong playbook của tin tặc. Trong bài viết này, chúng ta sẽ nói về những bí mật và cách giữ chúng khỏi mã nguồn là ưu tiên số một hiện nay để đảm bảo an toàn cho vòng đời phát triển phần mềm.
Bí mật là gì?
Bí mật là thông tin xác thực kỹ thuật số (khóa API, chứng chỉ, mã thông báo, v.v.) được sử dụng trong các ứng dụng, dịch vụ hoặc cơ sở hạ tầng. Giống như mật khẩu (cộng với một thiết bị trong trường hợp 2FA) được sử dụng để xác thực một người, một bí mật xác thực các hệ thống để cho phép khả năng tương tác. Nhưng có một điểm khó khăn: không giống như mật khẩu, các bí mật có nghĩa là được phân phối.
Để liên tục cung cấp các tính năng mới, các nhóm kỹ sư phần mềm cần kết nối ngày càng nhiều khối xây dựng với nhau. Các tổ chức đang theo dõi số lượng thông tin đăng nhập được sử dụng trên nhiều nhóm (nhóm phát triển, SRE, DevOps, bảo mật, v.v.) bùng nổ. Đôi khi các nhà phát triển sẽ giữ các khóa ở một vị trí không an toàn để dễ dàng thay đổi mã hơn, nhưng làm như vậy thường dẫn đến việc thông tin bị lãng quên và vô tình được công bố một cách nhầm lẫn.
Trong bối cảnh bảo mật ứng dụng, các bí mật được mã hóa cứng thực sự là một loại lỗ hổng bảo mật khác. Đầu tiên, vì mã nguồn là một tài sản rất dễ bị rò rỉ, có nghĩa là được sao chép, kiểm tra và chia nhỏ trên nhiều máy rất thường xuyên, nên các bí mật cũng bị rò rỉ. Tuy nhiên, đáng lo ngại hơn, chúng ta đừng quên rằng mã cũng có một bộ nhớ.
Bất kỳ cơ sở mã nào cũng được quản lý bằng một số loại hệ thống kiểm soát phiên bản (VCS), lưu giữ dòng thời gian lịch sử của tất cả các sửa đổi từng được thực hiện đối với nó, đôi khi kéo dài hàng thập kỷ. Vấn đề là những bí mật vẫn còn giá trị có thể được che giấu ở bất cứ đâu trên dòng thời gian này, mở ra một chiều hướng mới cho bề mặt tấn công. Thật không may, hầu hết các phân tích bảo mật chỉ được thực hiện trên trạng thái hiện tại, sẵn sàng triển khai của một cơ sở mã. Nói cách khác, khi nói đến các thông tin xác thực nằm trong một cam kết cũ hoặc thậm chí là một chi nhánh chưa bao giờ được triển khai, những công cụ này hoàn toàn mù mờ.
Sáu triệu bí mật được đẩy lên GitHub
Năm ngoái, theo dõi các cam kết được đẩy lên GitHub trong thời gian thực, GitGuardian đã phát hiện hơn 6 triệu bí mật bị rò rỉ, tăng gấp đôi con số so với năm 2020. Trung bình, 3 trong số 1.000 cam kết có thông tin xác thực, cao hơn năm ngoái 50%.
Một phần lớn những bí mật đó là cho phép truy cập vào các nguồn lực của công ty. Không có gì ngạc nhiên khi kẻ tấn công tìm cách giành được chỗ đứng trong hệ thống doanh nghiệp trước tiên sẽ xem xét các kho lưu trữ công khai của nó trên GitHub, sau đó xem xét các kho lưu trữ thuộc sở hữu của nhân viên. Nhiều nhà phát triển sử dụng GitHub cho các dự án cá nhân và có thể bị rò rỉ do nhầm lẫn thông tin đăng nhập của công ty (vâng, nó xảy ra thường xuyên!).
Với thông tin xác thực hợp lệ của công ty, những kẻ tấn công hoạt động với tư cách là người dùng được ủy quyền và việc phát hiện lạm dụng trở nên khó khăn. Thời gian để một thông tin đăng nhập bị xâm phạm sau khi được đẩy lên GitHub chỉ là 4 giây, có nghĩa là nó phải được thu hồi và xoay vòng ngay lập tức để vô hiệu hóa nguy cơ bị vi phạm. Vì mặc cảm, hoặc thiếu kiến thức kỹ thuật, chúng ta có thể thấy lý do tại sao mọi người thường đi sai đường để thoát khỏi tình trạng này.
Một sai lầm tồi tệ khác đối với các doanh nghiệp là dung túng sự hiện diện của các bí mật bên trong các kho lưu trữ không công khai. Báo cáo Sprawl State of Secrets của GitGuardian nhấn mạnh thực tế là các kho tư nhân che giấu nhiều bí mật hơn so với các kho lưu trữ công khai. Giả thuyết ở đây là các kho lưu trữ riêng tư mang lại cho chủ sở hữu cảm giác an toàn giả tạo, khiến họ bớt lo ngại hơn một chút về những bí mật tiềm ẩn ẩn trong cơ sở mã.
Đó là bỏ qua thực tế rằng những bí mật bị lãng quên này một ngày nào đó có thể có tác động tàn khốc nếu bị tin tặc thu hoạch.
Công bằng mà nói, các đội bảo mật ứng dụng đều nhận thức rõ vấn đề. Nhưng khối lượng công việc phải thực hiện để điều tra, thu hồi và luân phiên các bí mật được cam kết hàng tuần, hoặc đào bới trong nhiều năm lãnh thổ chưa được khám phá, đơn giản là quá sức.
Vi phạm dòng tiêu đề … và phần còn lại
Tuy nhiên, có một sự cấp bách. Tin tặc đang tích cực tìm kiếm các “dorks” trên GitHub, đây là các mẫu dễ dàng nhận ra để xác định các bí mật bị rò rỉ. Và GitHub không phải là nơi duy nhất mà chúng có thể hoạt động, bất kỳ cơ quan đăng ký nào (như Docker Hub) hoặc bất kỳ rò rỉ mã nguồn nào cũng có thể trở thành mỏ vàng để tìm các vectơ khai thác.
Bằng chứng là, bạn chỉ cần xem xét các vi phạm được tiết lộ gần đây: một công cụ yêu thích của nhiều dự án mã nguồn mở, Codecov là một công cụ bảo vệ mã. Năm ngoái, nó đã bị xâm nhập bởi những kẻ tấn công đã giành được quyền truy cập bằng cách trích xuất thông tin xác thực tài khoản đám mây tĩnh từ hình ảnh Docker chính thức của nó. Sau khi truy cập thành công kho mã nguồn chính thức, họ có thể giả mạo tập lệnh CI và thu thập hàng trăm bí mật từ cơ sở người dùng của Codecov.
Gần đây hơn, toàn bộ cơ sở mã của Twitch đã bị rò rỉ, làm lộ ra hơn 6.000 kho Git và 3 triệu tài liệu. Mặc dù có rất nhiều bằng chứng chứng minh mức độ trưởng thành nhất định của AppSec, nhưng gần 7.000 bí mật vẫn có thể được tiết lộ! Chúng ta đang nói về hàng trăm khóa AWS, Google, Stripe và GitHub. Chỉ một vài trong số chúng là đủ để triển khai một cuộc tấn công toàn diện vào các hệ thống quan trọng nhất của công ty. Lần này không có dữ liệu khách hàng nào bị rò rỉ, nhưng đó chủ yếu là may mắn.
Vài năm trước, Uber không may mắn như vậy. Một nhân viên đã vô tình xuất bản một số mã công ty trên một kho lưu trữ GitHub công khai, đó là của chính anh ta. Tin tặc đã tìm ra và phát hiện thấy các khóa của nhà cung cấp dịch vụ đám mây cấp quyền truy cập vào cơ sở hạ tầng của Uber. Một vụ vi phạm lớn xảy ra sau đó.
Điểm mấu chốt là bạn không thể chắc chắn khi nào một bí mật sẽ bị khai thác, nhưng điều bạn phải biết là các tác nhân độc hại đang theo dõi các nhà phát triển của bạn và họ đang tìm kiếm mã của bạn. Cũng nên nhớ rằng những sự cố này chỉ là phần nổi của tảng băng chìm và có thể còn nhiều vụ vi phạm khác liên quan đến bí mật không được tiết lộ công khai.
Sự kết luận
Bí mật là thành phần cốt lõi của bất kỳ ngăn xếp phần mềm nào và chúng đặc biệt mạnh mẽ, do đó chúng cần được bảo vệ rất mạnh mẽ. Bản chất phân tán của chúng và các phương thức phát triển phần mềm hiện đại khiến chúng ta rất khó kiểm soát nơi chúng đến, có thể là mã nguồn, nhật ký sản xuất, hình ảnh Docker hoặc các ứng dụng nhắn tin tức thì. Khả năng phát hiện và khắc phục bí mật là điều bắt buộc vì ngay cả những bí mật cũng có thể bị khai thác trong một cuộc tấn công dẫn đến một vi phạm lớn. Các kịch bản như vậy xảy ra hàng tuần và khi ngày càng có nhiều dịch vụ và cơ sở hạ tầng được sử dụng trong thế giới doanh nghiệp, số lượng rò rỉ đang tăng lên với tốc độ rất nhanh. Hành động càng sớm thì càng dễ bảo vệ mã nguồn khỏi các mối đe dọa trong tương lai.
Lưu ý – Bài viết này được viết bởi Thomas Segura, người viết nội dung kỹ thuật tại GitGuardian. Thomas vừa là nhà phân tích vừa là nhà tư vấn kỹ sư phần mềm cho nhiều công ty lớn của Pháp.
.
