Mới đây, trong chuyến làm việc tại Mát- xcơ- va, chuyên gia an toàn thông tin Steve Lipner đã chia sẻ với tác giả bài báo nhiều vấn đề xung quanh chủ đề đang được đề cập đến ở đây. Steve Lipner là con người kỳ lạ, những ghi chép của ông về vấn đề các lỗ hổng (vulnerability) trong phần mềm đã được thực hiện từ 40 năm về trước. Giờ đây, ông đang làm việc cho Microsoft và chịu trách nhiệm về chiến lược an toàn trong phát triển phần mềm, mà nòng cốt của nó là chính sách Security “Phát triển chu kỳ sống an toàn của phần mềm” (Development Lifecycle SDL) được hãng này phê duyệt vào năm 2004.

Sử dụng các công cụ SDL trong quá trình phát triển ứng dụng

Xét về bản chất, SDL là tập hợp những kinh nghiệm thực tế, những cách thức tiếp cận đã được kiểm nghiệm và những công cụ giúp lập trình viên viết nên những đoạn mã an toàn. Có lẽ điều thú vị nhất khi mới tiếp cận với SDL là bộ công cụ giúp viết mã an toàn và để kiểm tra (test) ứng dụng nhằm tìm ra các lỗ hổng. Một số công cụ trước đây chỉ được dùng trong nội bộ hãng Microsoft, nay đã được công bố rộng rãi cho những người quan tâm sử dụng. Phần lớn các công cụ này không chỉ hữu ích đối với những chuyên gia xây dựng phần mềm mà còn đối với tất cả những người làm việc trong lĩnh vực an toàn thông tin. Trong vòng hai năm gần đây, số lượng các công cụ đã tăng lên đáng kê và chức năng của chúng được giới thiệu sau đây.

BinScope Binary Analyzer

Chẳng phải ngẫu nhiên mà chúng ta bỏ nhiều thời gian vào việc tìm cách vượt qua cơ chế bảo mật Data Execution Prevention (DEP) và Address Space Layout Randomization (ASLR) - những công nghệ được sử dụng trong hệ điều hành nhằm ngăn chặn việc khai thác một số lỗ hổng bảo mật, ví dụ như lỗi tràn bộ đệm. Chúng thực sự là rào cản đáng kể đối với những người viết exploit. Khả năng khai thác các lỗ hổng bảo mật phụ thuộc rất nhiều vào việc có vượt qua được rào cản này hay không.

Để hình dung được các yêu cầu của SDL trong vấn đề này, hãy xem xét một trường hợp: “Bất kỳ ứng dụng nào cũng phải được bảo vệ bắt buộc bởi DEP và ASLR”. Để đáp ứng yêu cầu này, mã nguồn bắt buộc phải được biên dịch với các thông số tương ứng là /NXCOMPAT và /DYNAMICBASE. Đó chỉ là một trong số các yêu cầu. Với sự trợ giúp của Binscope SDL người ta có thể biết được ứng dụng có tuân thủ hết các khuyến cáo và yêu cầu SDL hay không. Bên cạnh đó, Binscope cũng thông báo về việc sử dụng các cấu trúc bị cấm dùng hay không nên dùng, ví dụ như sử dụng con trỏ dẫn tới hàm toàn cục.

AppVerifier

AppVerifier cũng là một công cụ phân tích, nhưng chức năng của nó là để phân tích động mã máy (native code) và phát hiện các lỗi của lập trình viên, những lỗi khó có thể bắt được trong quá trình kiểm tra thông thường. Phân tích động có nghĩa là chương trình sẽ được phân tích ngay trong quá trình hoạt động của nó (runtime test). AppVerifier theo dõi hoạt động của chương trình và kiểm tra xem nó có thực hiện những hành động nguy hiểm nào không. Ví dụ, nếu chương trình thực hiện tạo ra một đối tượng mà không có mô tả an toàn (security descriptor), hay truyền tham số vào hàm API theo cách không an toàn... thì AppVerifier sẽ đưa ra những cảnh báo thích hợp.

Attack Surface Analyzer Beta

Nhiệm vụ của Attack Surface Analyzer, như tên gọi của nó, là xác định bề mặt tấn công. Đây là một trong những công cụ mới nhất từ phòng thí nghiệm Microsoft. Công cụ phân tích này cho phép theo dõi những sự thay đổi trong hệ thống, xảy ra sau một tập hợp các hành động nhất định. Ví dụ, bằng cách “chụp hình” hệ thống trước và sau khi cài đặt phần mềm, rồi so sánh chúng, có thể xác định được mọi sự thay đổi: xuất hiện các file mới, bản ghi mới trong registry, các dịch vụ (service) mới, các thành phần ActiveX mới, các cổng mới được mở, thay đổi trong danh sách ACL .v.v.

Code Analysis for C/C++

Việc phân tích tự động mã nguồn để tìm ra các dấu hiệu có lỗ hổng được gọi là kiểm tra tĩnh (static test). Code Analysis for C/C++ là một công cụ phân tích mã tĩnh tiêu chuẩn (standard static code analyzer) và được cài đặt ngầm định vào một số phiên bản Visual Studio. Nó hỗ trợ tự động tìm kiếm trong mã máy (native code) các khả năng rò rỉ bộ nhớ, các ngoại lệ (exclusion) không bị bẫy, các vấn đề liên quan đến hiệu năng và các lỗ hổng an toàn.

Microsoft Code Analysis Tool .NET (CAT .NET)

Đây cũng là công cụ để thực hiện việc kiểm tra tĩnh, nhưng là dành để phân tích mã quản lý được (managed code) như C#, Visual Basic .NET, J#, và hướng tới đối tượng chính là các ứng dụng web. CAT .NET cho phép tìm ra các điểm yếu tiềm ẩn mà có thể về sau mới bị khai thác thông qua các chuỗi tấn công như Cross-Site Scripting (XSS), SQL Injection và XPath Injection. Trước khi được công bố rộng rãi thì công cụ này chỉ được sử dụng trong phạm vi hãng Microsoft.

FxCop

Đây cũng là một công cụ kiểm tra tĩnh để phân tích mã có thể quản lý (managed code). Thực ra, nó không kiểm tra mã nguồn mà kiểm tra mã đối tượng đã được biên dịch. Về bản chất, FxCop kiểm tra các chương trình .NET xem có tuân thủ đúng các khuyến cáo về xây dựng thư viện .NET Framework hay không. FxCop phân tích mã CIL (Common Intermediate Language - ngôn ngữ trung gian được Microsoft phát triển cho nền tảng .NET) để xây dựng và duyệt đồ thị các lệnh gọi hàm trong nó nhằm kiểm tra xem có tồn tại các vấn đề sai sót hay không trong số hơn 200 vấn đề đã được biết.

Anti - Cross Site Scripting (Anti - XSS) Library

Rất nhiều lỗ hổng có thể được cảnh báo trước bằng cách cung cấp cho các nhà phát triển những công cụ thích hợp. Theo cách tiếp cận này, Anti - XSS ra đời nhằm mục đích giảm thiểu khả năng thực hiện tấn công XSS lên các ứng dụng web. Điểm đáng chú ý ở đây là trong Anti - XSS chứa Security Runtime Engine (SRE), mà về bản chất nó giống như là một bức tường lửa dành cho ứng dụng web - Web Application Firewall (WAF). Anti - XSS hoạt động dưới dạng một môđun HTTP và đảm bảo cho các ứng dụng web thêm một lớp bảo vệ mà không cần phải biên dịch lại.

SiteLock ATL Template

Nếu từng đọc các bài viết nói về tấn công lên thành phần ActiveX thì chúng ta sẽ biết lỗi trong thành phần ActiveX nguy hiểm như thế nào. Thư viện SiteLock Active Template không thể giúp loại trừ các lỗi có trong phần mã, nhưng có thể giảm đáng kể khả năng khai thác các lỗi này. Với sự trợ giúp của ATL ta có thể hạn chế việc thực thi các thành phần ActiveX bằng cách sử dụng một danh sách cho trước các tên miền, các vùng an toàn. Có thể thiết lập SiteLock ATL Template để các thành phần ActiveX chỉ thực thi trong phạm vi intranet (mạng nội bộ), chứ không thực thi trên các trang thuộc mạng internet. Rõ ràng, bằng cách hạn chế khả năng khai thác các lỗ hổng, ta có thể giảm đáng kể khả năng các cuộc tấn công tiềm tàng.

Banned.h

Nếu nói về phát triển ứng dụng trên C/C++ thì nguy cơ trong code có những lệnh cho phép thực thi tấn công kiểu tràn bộ đệm (buffer overflow) và tương tự là rất lớn. Danh sách các lệnh kiểu này cũng rất dài: đó là các hàm làm việc với chuỗi ký tự (xstrcpy(), strcat(), gets(), sprintf(), printf(), snprintf(), syslog()); các hàm hệ thống (access(), chown(), chgrp(), chmod(), tmpfile(), tmpnam(), tempnam, mktemp()), và cả các lệnh gọi hệ thống (exec(), system(), popen()). Để phân tích mã nguồn và tìm ra các lệnh nguy hiểm này, ta có thể dùng công cụ phân tích tĩnh Code Analysis for C/C++ như đã nói ở trên. Tuy nhiên, vẫn còn một lựa chọn khác, đó là sử dụng file tiêu đề (header file). Đặc biệt banned.h không cho phép dùng các hàm mà từ lâu đã không được khuyến khích sử dụng (và tất nhiên là bị cấm bởi SDL).

SDL Threat Modeling Tool

Mô hình hóa hiểm họa (threat modeling) là một phần quan trọng trong việc thiết kế một sản phẩm phần mềm. Kết quả của việc mô hình hóa là một sơ đồ các thành phần chính của hệ thống tương lai cùng với các đánh dấu giới hạn tin tưởng trên đó. SDL Threat Modeling Tool là công cụ cho phép xây dựng và phân tích mô hình hiểm họa, qua đó nhận biết được những nguy hiểm tiềm tàng và đưa ra biện pháp giảm nhẹ nó.

SDL Proccess Template

Đây là khuôn mẫu (template) được phát triển cho Visual Studio. Nó tự động tích hợp các thành phần của SDL vào môi trường Visual Studio, giúp cho việc tuân thủ các yêu cầu của SDL khi tạo một dự án mới được dễ dàng hơn.

MiniFuzz File Fuzzer

Chiếu theo chính sách SDL, một trong những công đoạn bắt buộc khi kiểm tra (test) ứng dụng là fuzzing, tức là kiểm tra bằng các dữ liệu đầu vào ngẫu nhiên. Minifuzz File Fuzzer là công cụ kiểm tra mờ (fuzzy testing) cơ bản, được phát triển nhằm cho phép các chuyên gia không thuộc lĩnh vực an toàn, không có kiến thức về kiểm tra mờ cũng có thể thực hiện được việc kiểm tra này. Công cụ này đưa tới đầu vào của ứng dụng được kiểm tra các giá trị khác nhau nhằm tìm ra những ngoại lệ chưa được xử lý.

SDL Regex Fuzzer

Là công cụ kiểm tra mờ các biểu thức chính quy (Regex). SDL Regex Fuzzer cho phép kiểm tra các biểu thức chính quy để phát hiện các lỗ hổng loại “từ chối dịch vụ”. Đây là nhiệm vụ không đơn giản bởi các biểu thức chính quy thường chứa các mệnh đề có độ phức tạp hàm mũ về thời gian. Các biểu thức dạng này có thể bị lợi dụng để thực hiện tấn công từ chối dịch vụ. Công cụ SDL Regex Fuzzer cho phép tìm kiếm và chỉ ra sự có mặt của các biểu thức nguy hiểm này ngay trong quá trình phát triển ứng dụng.

Các công cụ được nhắc đến trên đây có thể tải về từ địa chỉ: http://www.microsoft.com/download/en/details.aspx?id=464. Như vậy, song song với quá trình phát triển các phần mềm ứng dụng, việc nghiên cứu các công cụ để có thể kiểm tra và tìm ra những lỗ hổng trong chương trình phần mềm là hết sức cần thiết và cần được sự quan tâm của các tổ chức hoạt động trong lĩnh vực CNTT.