1. Trang chủ
  2. » Công Nghệ Thông Tin

Kỹ thuật kiểm thử an ninh bảo mật dựa trên công nghệ FUZZING phân tán

99 478 2

Đang tải... (xem toàn văn)

Tài liệu hạn chế xem trước, để xem đầy đủ mời bạn chọn Tải xuống

THÔNG TIN TÀI LIỆU

Thông tin cơ bản

Định dạng
Số trang 99
Dung lượng 2,64 MB

Nội dung

Nhiều lỗ hổng trong các phần mềm thông dụng như Google Chrome, Microsoft Word… đã được phát hiện dựa trên công nghệ này.. Lỗi tràn bộ đệm là lỗi của chương trình thực hiện sao chép dữ li

Trang 1

LỜI CAM ĐOAN

Tôi xin cam đoan những gì mà tôi viết ra trong luận văn này là do sự tìm hiểu và

nghiên cứu của bản thân Mọi kết quả nghiên cứu cũng như ý tưởng của các tác giả khác đều được trích dẫn đầy đủ

Luận văn này cho đến nay vẫn chưa hề được bảo vệ tại bất kỳ một hội đồng bảo vệ luận văn thạc sĩ nào trên toàn quốc cũng như nước ngoài và cho đến nay chưa hề được công bố trên bất kỳ phương tiện thông tin nào

Tôi xin hoàn toàn chịu trách nhiệm về những gì mà tôi đã cam đoan trên đây

Hà Nội, ngày 02 tháng 9 năm 2013

Tác giả

Lê Đức Anh

Trang 2

LỜI CẢM ƠN

Trước tiên, tôi xin phép bày tỏ lòng biết ơn chân thành tới PGS.TS Huỳnh Quyết

Thắng đã tận tình giúp đỡ tôi hoàn thành luận văn này

Tôi cũng xin chân thành cảm ơn các thầy cô ở Viện Công nghệ Thông tin và Truyền thông của Đại học Bách Khoa Hà Nội đã giảng dạy và truyền đạt cho tôi những kiến thức quí báu trong suốt quá trình học tập trong suốt thời gian của khóa Thạc sĩ 2011 Cuối cùng, không kém phần quan trọng, xin cảm ơn các đồng nghiệp ở Bkav Security

đã tạo điều kiện để tôi có cơ hội biến nghiên cứu trong luận văn này thành hiện thực

Hà Nội, ngày 02 tháng 9 năm 2013

Lê Đức Anh

Trang 4

2.8.2 Phân tích khả năng khai thác của lỗi 41

3.1.4 Trình duyệt: Đích ngắm số một của tội phạm mạng 50

3.2.1 Mô hình Fuzzing có thể đơn giản hơn, mang tính phân tán sẵn 523.2.2 Xuất hiện các lỗi liên quan tới xử lý bộ nhớ nguy hiểm khác 55

3.2.4 Ý tưởng cải tiến cơ chế sinh dữ liệu Fuzzing 603.3 Đề xuất phương pháp xây dựng hệ thống Fuzzing trình duyệt 61

Trang 5

B Hướng phát triển của đề tài 98

Trang 6

DANH MỤC CÁC HÌNH VẼ

Hình 1: Thống kê sâu Conficker (Nguồn: Bkis) 10

Hình 2: Thống kê về vùng ảnh hưởng của Stuxnet (Nguồn: Threatpost.com) 11

Hình 3: Thống kê về số lỗ hổng trong 25 năm (nguồn: SourceFire) 15

Hình 4: Thống kê về phần mềm có nhiều lỗ hổng nguy hiểm trong 25 năm (nguồn: SourceFire) 16

Hình 5: Thống kê về loại của lỗ hổng nguy hiểm trong 25 năm (nguồn: SourceFire) 16

Hình 6: Các hàm Format 21

Hình 7: Các tham số format 21

Hình 8: Quét các dịch vụ đang chạy với Nmap 23

Hình 9: Quét lỗ hổng Website với Acunetix 24

Hình 10: Kiểm thử đâm xuyên với Metasploit 25

Hình 11: Phần mềm Internet Explorer khi gặp lỗi xử lý 27

Hình 12: GS Miller 28

Hình 13: Mô hình Fuzzing cổ điển 29

Hình 14: Mô hình Fuzzing thu gọn 30

Hình 15: Lưu đồ hoạt động của quá trình Fuzzing 31

Hình 16: Fuzzing với cơ chế phản hồi từ debugger 39

Hình 17: Các mức của lỗ hổng phần mềm 42

Hình 18: Một mô hình fuzzing phân tán 43

Hình 19: Thống kê về thị phần các trình duyệt vào tháng 10/2012 (Nguồn: Wikimedia) 46

Hình 20: Một trang HTML đơn giản 47

Hình 21: Trang HTML được hiển thị trên trình duyệt Internet Explorer 10 48

Hình 22: Các thành phần cơ bản trong trình duyệt 48

Hình 23: Luồng thực thi của một Rendering Engine đơn giản 49

Hình 24: Số lỗ hổng trình duyệt trong giai đoạn 2007-2011 51

Hình 25: Tự động tải lại trang Web qua mã Javascript 52

Hình 26: Mô hình fuzzing không cần debugger 53

Hình 27: Mô hình fuzzing không có debugger & server riêng 54

Hình 28: Màn hình của Cross_Fuzz khi hoạt động 55

Hình 29: File HTML demo lỗi CVE-2012-4792 56

Hình 30: Sinh dữ liệu Fuzzing với Python 58

Hình 31: Các bước hoạt động trong LangFuzz 60

Hình 32: Các bước trong xây dựng hệ thống 61

Hình 33: Dẫn hướng biên dịch trong zBNF 66

Hình 34: Ví dụ sử dụng zBNF 67

Hình 35: Luật sinh dữ liệu chưa được chuẩn hóa 68

Hình 36: Các luật của dạng chuẩn Chomsky 68

Hình 37: Các bước của quá trình biên dịch 69

Hình 38: FSM của quá trình Tokenizing dữ liệu zBNF 70

Hình 39: Lưu đồ lưu kết quả biên dịch 72

Hình 40: Lưu đồ giải thuật không đệ quy sinh dữ liệu fuzzing 73

Trang 7

Hình 42: Mô hình Fuzzing phân tán hay Fuzzing Cluster 76

Hình 43: Mã các Exception và ý nghĩa 83

Hình 44: Biên dịch dữ liệu zBNF 85

Hình 45: Dữ liệu mẫu được sinh ra từ đặc tả zBNF 85

Hình 46: Trang Web hiển thị quá trình Fuzzing 86

Hình 47: Quá trình fuzzing ở phía agent 86

Hình 48: Hiển thị các lỗi đã fuzz được trong Crash Bench 87

Hình 49: Văn phạm dùng zBNF cho fuzz các tag 91

Hình 50: Các trình duyệt và lỗi được lựa chọn để fuzz 92

Hình 51: Cây DOM 93

Hình 52: Văn phạm cho thí nghiệm đo hiệu suất 94

Hình 53: Số liệu thu được từ thí nghiệm đo hiệu suất 95

Hình 54: Sự biến đổi hiệu suất theo số máy tham gia 95

Trang 8

MỞ ĐẦU

A Tình hình an ninh ứng dụng hiện nay

B Giải pháp đảm bảo chất lượng phần mềm

C Nhiệm vụ của đề tài

Trang 9

A Tình hình an ninh ứng dụng hiện nay

Với sự phát triển như vũ bão của công nghệ thông tin và truyền thông hiện nay, chiếc máy tính đã trở nên thân thiết với chúng ta Có lẽ có nhiều bạn còn phải gắn bó với máy tính trong công việc riêng thường ngày của mình Nếu bạn là lập trình viên, môi trường phát triển tích hợp (IDE) nào quen thuộc với bạn nhất? Nếu là nhân viên văn phòng, trình xử lý văn bản nào mà bạn hay dùng nhất? Hoặc giả dụ, đơn thuần bạn là một gamer, bạn đã thử qua game Dante's Inferno, tựa game hot nhất mùa hè 2010 này chưa?

Môi trường mạng internet tạo điều kiện rất tốt cho các ứng dụng len lỏi vào từng ngõ ngách của đời sống của con người Các dịch vụ thương mại điện tử (E-commerce) ngày càng nở rộ tại Việt Nam như thanh toán online, mua hàng online Theo một báo cáo khảo sát năm 2008, 40% doanh nghiệp có doanh thu từ thương mại điện tử và mức doanh thu ấy chiếm 15% tổng doanh thu Một hướng khác đó đang được đẩy mạnh là ứng dụng công nghệ thông tin trong xây dựng chính phủ điện tử, nhằm giúp công tác quản lý nhà nước hiệu quả hơn, minh bạch hóa, giảm chi phí, phục vụ nhân dân và doanh nghiệp tốt hơn

Tuy nhiên, nhiều hacker đã lợi dụng internet cho các mục đích xấu Bạn tưởng tượng ra sao nếu một ngày tài khoản ngân hàng của mình bị rút một số tiền lớn một cách "đầy bí ẩn"? Bạn có biết kẻ nào đã gây ra các cuộc tấn công DDoS vào website của chính phủ

Mĩ và Hàn Quốc mà báo chí đã tốn rất nhiều giấy mực trong năm 2009 chưa? Các phần mềm phổ biến như Windows Media Player, Winamp, các trình duyệt web Internet Explorer, Firefox đang là mục tiêu rất hấp dẫn của hacker Hầu như ngày nào, trên các trang tin an ninh mạng cũng công bố lỗi của các phần mềm Hãng phần mềm

Microsoft hàng tháng đều phải công bố các bản vá cho sản phẩm của mình Ngay trong

Trang 10

tháng 4/2010 vừa rồi, Microsoft tung ra 10 bản cập nhật an ninh, quá nửa trong số đó là các lỗi cực kì nguy hiểm

Trước đó trong năm 2009, hàng triệu máy tính chạy hệ điều hành Windows XP trên toàn thế giới bị nhiễm sâu conficker Lỗ hổng bảo mật bị khai thác ở đây phát sinh từ trong Windows RPC và Microsoft bít lại bằng bản vá khẩn cấp mang mã số MS08-67 Sâu Conficker rất phức tạp, nguy hiểm và đủ khả năng tạo mạng máy tính ma để tấn công hạ gục bất kỳ hệ thống máy tính nào chưa được vá lỗ hổng Theo thống kê của trung tâm an ninh mạng Bkis, đã có rất nhiều biến thể của Conficker xuất hiện Trung Quốc là nước có số lượng máy tính bị nhiễm nhiều nhất

Hình 1: Thống kê sâu Conficker (Nguồn: Bkis)

Trong năm 2010, cả thế giới xôn xao về sâu Stuxnet, vũ khí mạng đầu tiên được biết đến Stuxnet đã được xem là một trong những virus máy tính tinh vi nhất từng được tạo

ra, đã lây nhiễm vào hàng trăm ngàn hệ thống máy tính nhờ khai thác 20 lỗ hổng xếp

Trang 11

Stuxnet phá hoại các hệ thống SCADA dùng trong các nhà máy công nghiệp, mà trong trường hợp gần đây nhất là chiếm quyền kiểm soát hệ thống phát điện cho tổ hợp máy làm giàu uranium – nguyên liệu dùng trong công nghiệp nguyên tử tại Iran

Hình 2: Thống kê về vùng ảnh hưởng của Stuxnet (Nguồn: Threatpost.com)

Tiếp đó, trong năm 2012, xuất hiện hàng loạt các vũ khí mạng khác như Gauss, Flame, Mini Flame, Tác hại của chúng như thế nào, đến nay vẫn chưa có con số cụ thể Và người ta cũng chưa thể biết rằng: liệu chiến tranh mạng (cyber war) đã diễn ra hay

chưa & diễn ra từ lúc nào

Trang 12

Vấn đề an ninh mạng nói chung và an ninh ứng dụng nói chung đang đặt ra rất nhiều vấn đề nóng bỏng, đòi hỏi phải có sự quan tâm đúng mức từ phía người dùng, tổ chức, doanh nghiệp và cả từ phía nhà nước

B Giải pháp đảm bảo chất lượng phần mềm

Làm thế nào để hạn chế tối đa những lỗ hổng an ninh trong phần mềm ứng dụng?

Từ góc nhìn của các công ti phát triển phần mềm đó là: phải đảm bảo tốt nhất chất lượng phần mềm trước khi tung ra thị trường Hoạt động kiểm thử phần mềm là qui trình bắt buộc trong các dự án phát triển phần mềm Với mục đích phát hiện lỗi, kiểm thử phần mềm thường phải trải qua các bước: tạo dữ liệu thử, thực thi phần mềm trên

dữ liệu thử và quan sát kết quả nhận được Bước tạo dữ liệu đóng vai trò quan trọng nhất, ảnh hưởng lớn nhất tới khả năng phát hiện lỗi

Tuy nhiên, việc kiểm thử phần mềm hiện nay đa phần được thực hiện một cách thủ công, không có hiệu quả cao trong việc phát hiện những lỗ hổng an ninh tiềm tàng Công nghệ Fuzzing chính là một giải pháp cho vấn đề trên Với khả năng tự động hóa cao độ cùng với cơ chế phát hiện lỗ hổng hiệu quả, công nghệ này được rất nhiều hãng quan tâm sử dụng Tuy rằng, fuzzing đã ra đời được 20 năm, nhưng vẫn có nhiều vấn

đề cần phải nghiên cứu, nhất là cải tiến hơn nữa hiệu suất và độ tin cậy của fuzzing

C Nhiệm vụ của đề tài

Tên đề tài (tiếng Việt): Kiểm thử an toàn cho trình duyệt dựa trên kỹ thuật Fuzzing

phân tán

Tên đề tài (tiếng Anh): Security Testing for Browsers with Distributed Fuzzing

Technique

Trang 13

Lỗ hổng phần mềm (software vulnerability) dùng để chỉ lỗi của phần mềm trong quá trình xử lý dữ liệu đầu vào Do xử lý không tốt, một số lỗi có thể dẫn tới khả năng bị hacker khai thác, tấn công, thậm chí chiếm dụng toàn bộ hệ thống

Lỗ hổng phần mềm có thể phân ra rất nhiều loại, tuy nhiên, đối với phần mềm thông thường, các lỗ hổng liên quan tới bộ nhớ (như tràn bộ đệm, dangling pointer …) là rất thường gặp và tương đối nguy hiểm

Dữ liệu gây ra các lỗi liên quan tới bộ nhớ có thể có khuôn dạng, rất dễ nhận thấy như

dữ liệu có độ dài lớn, số nguyên lớn…Tuy nhiên, trong một số trường hợp khó hơn, dữ liệu đó thực tế là không thể xác định được ngay từ ban đầu và cần phải nhiều phép thử

để xác định Để đảm bảo chất lượng phần mềm, ta cần một giải pháp để tự động sinh

dữ liệu, kiểm soát hành vi của phần mềm trong khi xử lý dữ liệu đó Và công nghệ Fuzzing là một câu trả lời cho nhu cầu đó

Kỹ thuật Fuzzing là kỹ thuật kiểm thử hộp đen có tính tự động hóa cao, có thể dùng để phát hiện các lỗ hổng an ninh có trong phần mềm Nhiều lỗ hổng trong các phần mềm thông dụng như Google Chrome, Microsoft Word… đã được phát hiện dựa trên công nghệ này

Mục đích của đề tài (các kết quả cần đạt được):

Xây dựng hệ thống kiểm thử trình duyệt dựa trên Fuzzing với các đặc trưng như sau:

 Xây dựng ngôn ngữ đặc tả dữ liệu fuzzing, giúp mô các loại dữ liệu chỉ có thể được

mô tả bằng văn phạm phi ngữ cảnh (Context Free Grammar) như Javascript, CSS

… Đây là đối tượng xử lý chính của các trình duyệt Web hiện nay

 Phân tán xử lý

Trang 14

CHƯƠNG I: CƠ SỞ LÝ THUYẾT CHUNG

1.1 Tổng quan về lỗ hổng phần mềm

1.2 Kiểm thử bảo mật

1.3 Kết chương

Trang 15

1.1 Tổng quan về lỗ hổng phần mềm

Thuật ngữ "lỗ hổng" (vulnerability[1]) được dùng ở đây để chỉ những lỗi lập trình có thể

bị khai thác (exploitable), cho phép hacker lợi dụng để thực thi mã độc trên máy người

sử dụng, đánh cắp thông tin quan trọng

Hình 3: Thống kê về số lỗ hổng trong 25 năm (nguồn: SourceFire)

Qua 25 năm, số lỗ hổng phần mềm có chiều hướng gia tăng nhanh chóng trong giai

đoạn 1988-2005, với một chút tạm lắng trong năm 2003 Số lỗ hổng đạt đỉnh vào năm

2006, và liên tục giảm cho tới năm 2011 Tuy nhiên, cho đến cuối năm 2012, số lỗ

hổng lại tiếp tục tăng trở lại

Phần mềm với nhiều lỗ hổng nhất là Linux Kernel với 937 lỗ hổng Trình duyệt

Chrome ‘vượt mặt’ Internet Explorer về số lượng lỗ hổng gặp phải

Trang 16

Hình 4: Thống kê về phần mềm có nhiều lỗ hổng nguy hiểm trong 25 năm (nguồn: SourceFire)

Theo một thống kê khác về thành phần của các lỗi nguy hiểm (Common Vulnerability Scoring System (CVSS) lớn hơn 7), các lỗ hổng liên quan tới tràn bộ đệm chiếm phần lớn (23%):

Hình 5: Thống kê về loại của lỗ hổng nguy hiểm trong 25 năm (nguồn: SourceFire)

Trang 17

Lỗ hổng trên phần mềm có thể được đặc trưng bởi các yếu tố sau:

Nền tảng (platform) mà phần mềm hoạt động: trước đây, môi trường Desktop

với các ứng dụng chạy trên hệ điều hành là đích nhắm của nhiều hacker Tuy nhiên,

do sự phát triển của công nghệ điện toán, các nền tảng khác như web, mobile cũng

là mục tiêu đầy tiềm năng để hacker khai thác

Mức độ phổ dụng của phần mềm: phần mềm càng phổ biến, nếu có lỗ hổng thì

càng nghiêm trọng

Tính chất khai thác: có 2 loại hình tấn công phổ biến là tấn công từ xa (remote

attack) hoặc tấn công local Tấn công từ xa thường được thực hiện qua môi trường mạng và nguy hiểm hơn và có tính chất lây nhiễm nhiều hơn Sự kiện sâu Conficker

là một ví dụ điển hình Conficker hay Downadup lợi dụng một lỗi bảo mật dịch vụ Windows Server tích hợp trong hầu hết mọi phiên bản Windows - từ Windows

2000, XP, Vista, Server 2003 đến Server 2008 - để tấn công và lây nhiễm lên PC người dùng lẫn mạng nội bộ mà máy tính đó kết nối đến Khi được kích hoạt,

Conficker sẽ khóa một số dịch vụ hệ thống như Windows Automatic Update,

Windows Security Center, Windows Defender, and Windows Error Reporting Kế đến, Conficker kết nối đến một máy chủ chứa mã độc để tải các loại mã độc khác cài đặt lên máy tính nạn nhân Theo một thống kê không chính thức, cho tới tháng 4/2012, đã có trên 220 triệu máy tính trên toàn cầu bị nhiễm conficker

Độ khó của việc khai thác: các lỗ hổng đã được phát hiện sẽ được các nhà sản

xuất phần mềm cập nhật để bảo vệ người dùng Nhiều cơ chế mới được thêm vào

để đảm bảo cho điều này Ví dụ như cơ chế ASLR (Address Space Layout

Randomization) được đưa vào trong các phiên bản của Microsoft Windows bắt đầu

từ năm 2007 Việc vượt qua được câc cơ chế bảo vệ đó đòi hỏi nhiều kỹ năng và kiến thức, đôi khi rất khó để hacker có thể tiến hành khai thác ứng dụng bị lỗi

Trang 18

Toàn bộ các thông tin trình bày ở trong luận văn này sẽ tập trung vào lỗ hổng liên quan

tới xử lý bộ nhớ, lỗ hổng thường gặp nhất của các phần mềm Desktop thông thường

1.1.1 Lỗ hổng tràn bộ đệm

Bộ đệm (buffer) là một vùng nhớ liên tục có kích thước giới hạn trong máy tính Bộ đệm dùng để lưu trữ các giá trị tạm thời của biến, mảng hay một xâu phục vụ cho quá trình xử lý

Lỗi tràn bộ đệm là lỗi của chương trình thực hiện sao chép dữ liệu có kích thước lớn hơn vào một bộ đệm mà không thực hiện các thao tác kiểm tra biên, dẫn đến vùng nhớ phía sau bộ đệm bị ghi đè, vùng nhớ này có thể lại là một bộ đệm khác hoặc là vùng nhớ hệ thống… Kết quả là có thể làm chương trình hoạt động không chính xác hoặc đổ

vỡ

Các ngôn ngữ lập trình họ C và C++ không tự động so sánh kích thước dữ liệu sẽ được sao chép với kích thước của bộ đệm Do đó nếu người thiết kế chương trình không thêm đoạn mã kiểm tra kích thước dữ liệu vào, hoàn toàn có thể ghi đè lên vùng nhớ phía sau bộ đệm và những điều không lường trước có thể xảy ra

Bộ đệm có hai loại, bộ đệm trên stack và bộ đệm trên heap Stack dùng để chứa các biến cục bộ kích thước thường nhỏ, sử dụng trong hàm, được cấp phát khi hàm khởi tạo, giải phóng khi kết thúc hàm Bộ đệm trên heap có cấu trúc phức tạp hơn và được tham chiếu đến bởi con trỏ - thường là một biến trong stack, tuy nhiên cả hai đều có nguy cơ gặp lỗi tràn bộ đệm nếu không kiểm tra cẩn thận trước khi tao tác

Sau đây là một ví dụ về lỗi tràn bộ đệm trong một chương trình đơn giản:

Trang 19

void main( int argc, char* argv[]){

bộ nhớ hoặc chỉ số trong mảng Tất nhiên, phần lớn các lỗi tràn số nguyên là không thể khai thác được bởi vì bộ nhớ không bị ghi đè trực tiếp, nhưng nó thường hay dẫn tới các loại lỗi khác, mà điển hành là tràn bộ đệm

Sau đây là một ví dụ về lỗi tràn bộ đệm trong một chương trình đơn giản:

#include <stdio.h>

#include <string.h>

int main( int argc, char *argv[]){

Trang 20

1.1.3 Lỗ hổng format string

Lỗ hổng này xảy ra khi dữ liệu được truyền vào của một string được đánh giá như là lệnh đối với chương trình Theo cách này, kẻ tấn công có thể thực thi mã độc, gây ra các hành vi ảnh hướng tới tính bền vững của phần mềm Để hiểu thêm về cách tấn công này, ta cần phải hiểu một số thành phần như sau:

 Hàm format là hàm chuyển đổi như printf, fprintf, Các hàm đó được dùng để chuyển đổi các biến trong ngôn ngữ lập trình thành các string (có thể được hiểu bởi

Trang 21

 Chuỗi format là tham số của hàm format và nó là một string, chứa text và các ký tự format Ví dụ như: printf ("The magic number is: %d\n", 1911)

 Tham số format, ví dụ như %x, %d,

Bảng giới thiệu một số hàm format trong C/C++ và tham số format tương ứng:

fprint Ghi một chuỗi được định dạng vào file

printf Ghi ra màn hình một chuỗi được định dạng

sprintf Xuất ra một string

snprintf Tương tự như printf, nhưng có kiểu tra độ dài của buffer truyền vào

Sau đây là một đoạn mã bị lỗi format string Đoạn mã copy tham số truyền từ

command line vào một bộ đệm, sử dụng hàm snprintf():

Trang 22

int main( int argc, char **argv){

đã được thiết kế hay không [3]

Có sáu khía cạnh liên quan tới kiểm thử bảo mật đó là:

Tính riêng tư (Confidentiality): Chống lại thất thoát dữ liệu và dữ liệu chỉ được

gửi cho những đối tượng xác định

Tính toàn vẹn (Integrity): Dữ liệu nhận được bởi hệ thống là nguyên vẹn, không

bị sửa đổi dọc đường truyền

Tính xác thực (Authentication): Liên quan tới việc xác thực người sử dụng hệ

thống

Tính ủy quyền (Authorization): Xác định xem người sử dụng có được thực hiện

một số tác vụ nhất định trên hệ thống hay không Ví dụ: người dùng Admin có quyền thực hiện nhiều tác vụ hơn là người dùng bình thường

Tính sẵn sàng (Availability): Đảm bảo rằng thông tin và đường truyền luôn sẵn

sàng khi có yêu cầu Thông tin chỉ được cấp cho những người được ủy quyền

Tính không chối bỏ (Non-repudiation): Tính chất này là một cách để khẳng định

chắc chắn rằng: người đã gửi một thông điệp không thể chối bỏ rằng mình đã không làm điều đó, và ngược lại: người nhận cũng không thể chối bỏ rằng mình đã không nhận được thông điệp

1.2.2 Các thuật ngữ

Có các thuật ngữ sau trong lĩnh vực kiểm thử bảo mật:

Phát hiện (Discovery): mục đích của bước này là xác định các thành phần trong hệ

thống và các dịch vụ liên quan Nó không được sử dụng trong quá trình phát hiện lỗ

Trang 23

hổng, nhưng giúp cho việc xác định phiên bản của các phần mềm/firmware cũ để tìm các lỗ hổng liên quan

Hình 8: Quét các dịch vụ đang chạy với Nmap

Quét lỗ hổng: Sau Phát hiện, giai đoạn này sẽ xác định các nguy cơ bảo mật bằng

thủ công hoặc bằng việc sử dụng các công cụ tự động phát hiện lỗ hổng Các công

cụ trên thường được gọi là Fuzzer, là đối tượng nghiên cứu của luận văn này Hiện nay, có rất nhiều fuzzer với khả năng khác nhau trong phát hiện lỗ hổng của các phần mềm, website, giao thức …

Trang 24

Hình 9: Quét lỗ hổng Website với Acunetix

Đánh giá lỗ hổng (Vulnerability Assessment): Thuật ngữ này chỉ sự kết hợp của

2 giai đoạn Phát hiện và Quét lỗ hổng để xác định các lỗ hổng và đặt chúng trong ngữ cảnh liên quan để kiểm tra lại Việc kiểm tra lại có thể giúp loại bỏ các false positive và true negative [4] và xác định mức độ nguy hiểm của các lỗ hổng

Kiểm thử đâm xuyên (Penetration Test): Kiểu kiểm thử này áp dụng kiểu tấn

công được thực hiện bởi các hacker xấu Được xây dựng trên kết quả của Đánh giá

lỗ hổng, kết hợp với việc khai thác hệ thống Sử dụng cách tiếp cận này sẽ giúp ta

có được hiểu biết về khả năng của hacker để truy cập vào các thông tin riêng tư, ảnh hưởng tới tính toàn vẹn của dữ liệu hoặc tính sẵn sàng của dịch vụ… Mỗi bài kiểm tra được tiến hành theo một phương pháp xác định, có thể phát hiện các lỗ hổng mà các công cụ kiểm tra tự động không thể phát hiện Điều này có được là dựa vào kinh nghiệm và trình độ của người kiểm tra, kết hợp với nhiều công cụ liên quan

Kiểm thử đâm xuyên sẽ tập trung vào độ sâu của các cuộc tấn công, trong khi, Đánh giá lỗ hổng lại tập trung vào độ rộng

Trang 25

Hình 10: Kiểm thử đâm xuyên với Metasploit

Kiểm tra bảo mật (Security Audit): Kiểu kiểm tra này tập trung vào một phần

hẹp hơn, một chức năng của của hệ thống Có thể sử dụng tất cả các phương pháp nêu trên để tiến hành

Xem xét bảo mật (Security Review): Xác nhận lại xem các tiêu chuẩn về an toàn

thông tin có được áp dụng vào trong các thành phần hệ thống hoặc sản phẩm hay không Điều này thường được tiến hành theo các quy trình có sẵn như: xem lại mã nguồn, xem lại thiết kế…

1.3 Kết chương

Các nội dung của chương này đã trình bày ở mức độ tổng quan về một số loại lỗi hay gặp trong xử lý bộ nhớ của phần mềm và khái niệm về phương pháp kiểm thử bảo mật Trong chương tiếp theo, ta sẽ trình bày sâu hơn về Fuzzing: định nghĩa, cơ chế hoạt động, cũng như những điểm mạnh & yếu của phương pháp này

Trang 26

CHƯƠNG II: CƠ SỞ CỦA KỸ THUẬT FUZZING

2.1 Khái niệm

2.2 Lịch sử của Fuzzing

2.3 Mô hình fuzzing cổ điển

2.4 Phân loại phương pháp Fuzzing

2.5 Phân loại Fuzzer

2.6 Các bước của Fuzzing

2.7 Hạn chế của Fuzzing

2.8 Các vấn đề trong fuzzing

2.9 Kết chương

Trang 27

2.1 Khái niệm

Trong lĩnh vực an ninh ứng dụng, Fuzzing là kỹ thuật phát hiện lỗi phần mềm bằng cách cung cấp dữ liệu đầu vào cho chương trình, sau đó theo dõi và ghi lại lỗi xảy ra trong quá trình xử lý của chương trình[2] Dữ liệu không mong đợi thường là các giá trị

vượt ra ngoài biên, các giá trị đặc biệt Fuzzing là quá trình tự động hoặc bán tự động

lặp lại thao tác sinh dữ liệu và chuyển cho phần mềm xử lý Khái niệm Fuzzing thiên

về lý thuyết hơn là giải pháp cụ thể Các chương trình ứng dụng Fuzzing gọi là Fuzzer Tùy theo môi trường và ứng dụng cần kiểm tra mà người ta có các phương án khác nhau để xây dựng Fuzzer

Hình 11: Phần mềm Internet Explorer khi gặp lỗi xử lý

Dữ liệu fuzzing có thể là:

Dữ liệu kiểu xâu (string): xâu có độ dài lớn, hoặc chứa một số ký tự đặc biệt như

%x, %s, CLSID, HTTP …

Dữ liệu kiểu số nguyên: có thể là số nguyên dài 1 byte, 2 byte hay 4 byte, có thể có

dấu hay không dấu Các giá trị làm tràn số nguyên có thể sử dụng là MAX_INT, MAX_INT – 1, MAX_INT – 2 …

Trang 28

Các dữ liệu này cần được kết hợp với các dữ liệu thông thường khác trong quá trình fuzzing

http://pages.cs.wisc.edu/~bart/fuzz/

Năm 1999, trường đại học Oulu bắt đầu xây dựng các bộ kiểm thử PROTOS Các bộ kiểm thử đã được xây dựng qua việc nghiên cứu đặc tả giao thức sau đó tạo ra các gói tin “dị dạng” để kiểm tra xem ứng dụng cài đặt có xử lý đúng đắn nó hay không Việc tạo ra những bộ kiểm thử như vậy tốn khá nhiều công sức, nhưng một khi hoàn tất, sẽ

có thể áp dụng cho nhiều ứng dụng khác nhau của nhiều hãng phát triển khác nhau Một số lượng lớn lỗi đã được phát hiện trong quá trình fuzzing sau đó

Năm 2002, Microsoft đã quyết định đầu tư cho nhóm sáng lập PROTOS Năm 2003, các thành viên của nhóm đã thành lập Codenomicon, một công ty chuyên thiết kế và phát triển các sản phẩm fuzzing thương mại

Fuzzer cho các định dạng tệp tin bắt đầu xuất hiện năm 2004, cùng năm đó Microsoft công bố lỗi MS04-028, một lỗi của hệ điều hành trong xử lý ảnh định dạng JPEG Đích tiếp theo đó là các định dạng tài liệu của Microsoft Office Tại Blackhat 2005 nhiều công cụ Fuzzing định dạng tệp đã được giới thiệu như: FileFuzz, SPIKEfile và

notSPIKEfile

Trang 29

Tiếp đó, ActiveX lại trở thành mục tiêu mới khi có khá nhiều lỗi được phát hiện liên quan đến công nghệ này.Việc khai thác lỗi của ActiveX qua trình duyệt web khá dễ dàng Năm 2006 David Zimmer cho ra COMRaider, cùng năm đó H.D.Moore giới thiệu AxMan Cả hai công cụ đều tập trungvào những ActiveX có thể sử dụng được trong trình duyệt web Internet Explorer của Microsoft

Gần đây nhất, vào tháng 4/2010, trong bài phát biểu về những nỗ lực “fuzzing” của Microsoft tại hội thảo bảo mật CanSecWest, Tom Gallagher, trưởng bộ phận Microsoft

Office Security Test, cho biết: “Chúng tôi đã phát hiện và sửa chữa khoảng 1800 lỗi trong các mã Office 2010 Mặc dù số lượng này khá lớn nhưng điều đó không có nghĩa

là chúng tôi đã phát hiện ra 1800 vấn đề liên quan đến bảo mật Chúng tôi cũng kỳ vọng sẽ có thể sửa chữa được cả các lỗi không liên quan đến bảo mật” Liên quan đến

cơ cấu Distributed Fuzzing của Microsoft, Gallagher cho biết:“chúng tôi gọi đây là botnet cho fuzzing” Mạng “fuzzing” được khởi tạo bởi David Conger, một nhà thiết kế

phần mềm của nhóm Access Tuy nhiên, các thông tin liên quan tới framework này hầu như là không có

2.3 Mô hình fuzzing cổ điển

Fuzzer Phần mềm mục tiêu

Trang 30

Mô hình này [11] gồm có 3 thành phần cơ bản:

Target software: chính là phần mềm mà bạn cần kiểm tra

Fuzzer: tạo ra các dữ liệu test gửi tới debugger, liên tục yêu cầu kiểm tra xem phần

mềm có hoạt động bình thường hay không Nếu phần mềm đổ vỡ, thì yêu cầu

debugger khởi động lại phần mềm và ghi lại thông báo lỗi Fuzzer và Debugger giao tiếp với nhau qua IPC (Interprocess communicaton) theo một giao thức nhất định

Debugger: tương tác trực tiếp với phần mềm, nhận các lệnh và gửi phản hồi tới

fuzzer Cũng phải nói thêm rằng, ngoài Autodafe, debugger của các fuzzer hoạt động theo nguyên tắc một chiều, không có có thêm vòng phản hồi từ software để xem test case nào nên được ưu tiên tạo tiếp sau

Mô hình trên có thể được biểu diễn gọn hơn theo hình dưới đây:

Hình 14: Mô hình Fuzzing thu gọn

Phần mềm mục tiêu hoạt động dưới sự giám sát của Debugger, nó được biểu diễn như

là một khối nằm trong Debugger Cả 2 khối Debugger và phần mềm đều trao đổi dữ liệu với Fuzzer

Trang 31

Sinh dữ liệu fuzzing

Hình 15: Lưu đồ hoạt động của quá trình Fuzzing

2.4 Phân loại phương pháp Fuzzing

Theo phương pháp sinh dữ liệu, Fuzzer được chia làm hai loại lớn là intelligent fuzzing

và dumb fuzzing [23] Dumb fuzzing là phương pháp sinh dữ liệu để fuzz dựa vào mẫu dữ

liệu hợp lệ có sẵn, có thể là một tệp tin đúng chuẩn hoặc một gói tin bắt được, rồi sửa

đổi ngẫu nhiên và chuyển cho chương trình Intelligent fuzzing là phương pháp sinh ra

các bộ dữ liệu mới bằng cách mô phỏng lại giao thức mạng hoặc định dạng tệp Dumb fuzzing có ưu điểm là đơn giản, không đòi hỏi nhiều kiến thức về các định dạng file, các protocol, tuy nhiên thời gian thực thi có thể rất lâu Intelligent fuzzing thì ngược lại, đòi hỏi các bạn phải có kiến thức về mục tiêu cần fuzz, khá phức tạp; ưu điểm nổi bật là hiệu suất hơn hẳn dumb fuzzing

Trang 32

Tuy nhiên, bằng cách chia nhỏ hai phương pháp trên, phương pháp fuzzing có thể được chia thành 5 loại nhỏ hơn như sau:

Sử dụng các test case được sinh trước (Pregenerated Test Cases) Theo cách

này người thực hiện fuzzing sẽ sử dụng những bộ dữ liệu đặc biệt, cố định, được lập trình cứng, tạo ra những bộ dữ liệu này cần nhiều công sức Một khi tất cả các

bộ dữ liệu đã được gửi đi, quá trình fuzzing cũng kết thúc Điểm bất lợi của phương pháp này là khả năng hạn chế trong tận dụng lại dữ liệu cho các dự án fuzzing khác

sau này

Sinh dữ liệu ngẫu nhiên (Random) Dữ liệu được sinh ra ngẫu nhiên, liên tục và

gửi đi, không theo giao thức nào Cách này không hiệu quả, mặc dù vậy thật ngạc

nhiên là đã có những lỗi cực kỳ quan trọng đã được phát hiện bởi phương pháp này

Kiểm tra thủ công bằng thay đổi giao thức (Manual Protocol Mutation

Testing) Theo phương pháp này, không có một chương trình fuzzer tự động nào

Thực tế người nghiên cứu chính là fuzzer, họ chặn các giao thức, sửa đổi ngẫu

nhiên và chuyển đi Cách này được dùng chủ yếu cho các ứng dụng Web

Vét cạn (Mutation-based hay là Brute Force Testing) Phương pháp này bắt đầu

từ một mẫu dữ liệu hợp lệ, sửa từng byte, word, dword, hay xâu trong đó Phương pháp này có ưu điểm là không tốn công nghiên cứu giao thức và định dạng tệp, thời gian để xây dựng công cụ fuzzer nhanh Tuy nhiên mức độ bao trùm lệnh tùy thuộc việc chọn gói tin hay tệp mẫu ban đầu Phần lớn các giao thức và định dạng tệp khá phức tạp, do vậy số lượng mẫu ban đầu phải tương đối lớn để bao phủ hết các khả năng kiểm thử FileFuzz và notSPIKEfile là hai fuzzer mã nguồn mở sử dụng kỹ

thuật này

Tự động sinh dữ liệu cho giao thức (Automatic Protocol Generation Testing)

Đây là phương pháp cao cấp nhất hiện nay Thay vì tạo ra các bộ dữ liệu cứng để kiểm tra, người nghiên cứu sẽ xây dựng một ngữ pháp để mô tả giao thức sẽ hoạt

Trang 33

động thế nào, các đơn vị dữ liệu cơ bản, và trình tự hoạt động của giao thức Công việc này đòi hỏi thời gian và công sức nghiên cứu, nhưng công việc sau đó là dành cho fuzzer Thành công hay không là phụ thuộc vào việc người nghiên cứu có chỉ ra được khu vực nào có khả năng lỗi cao của giao thức hay không SPIKE và

SPIKEfile là những fuzzer loại này Hạn chế của phương pháp này là mất thời gian

để tìm hiểu và xây dựng ngữ pháp cho dự án fuzzing

2.5 Phân loại Fuzzer

2.5.1 Fuzzer cục bộ (Local fuzzer)

Phần mềm mục tiêu ở đây là phần mềm chạy trên cùng máy tính với fuzzer

Command-line fuzzer: Khi một ứng dụng bắt đầu chạy, nó thường được người

dùng truyền cho một vài tham số đầu gọi là command-line (tham số dòng lệnh) Ví dụ: khi người dùng click đúp lên một file doc, Microsoft Word sẽ được thực thi với tham số là đường dẫn đến tệp văn bản mà người dùng Fuzzer loại này sẽ sinh ra những command line đặc biệt dài, hoặc chứa những ký tự đặc biệt… rồi truyền cho

ứng dụng lúc bắt đầu thực thi Lỗi thuộc loại này rất ít và không nguy hiểm

Environment variable fuzzer: Tương tự như command-line fuzzer, các biến môi

trường cũng được hệ điều hành cung cấp cho ứng dụng để nó biết thông tin về môi trường làm việc hiện tại, thí dụ như đường dẫn thư mục hệ thống, đường dẫn thư mục làm việc, … Lỗi tràn bộ đệm loại này rất hiếm và không nguy hiểm Các

fuzzer điển hình là Sharefuzz và iFuzz

File format fuzzer: Một số lượng lớn ứng dụng sử dụng tệp để lưu trữ dữ liệu Tất

cả đều có thể gặp nguy hiểm khi khi dữ liệu không được xử lý đúng đắn Đây chính là mục tiêu của fuzzer loại này Các công cụ fuzz tệp là FileFuzz,

notSPIKEfile, SPIKEfile, PAIMEIfilefuzz

Trang 34

2.5.2 Fuzzer từ xa (Remote fuzzer)

Đây là trường hợp khi fuzzer và phần mềm mục tiêu không cùng nằm trên một máy, ví

dụ như khi thực thi fuzzing một máy chủ SMTP, POP3, …

Fuzzer giao thức mạng: Fuzzer các giao thức mạng có thể chia thành hai loại:

Fuzz các giao thức đơn giản: thường có hoặc không có chế độ xác thực, dữ

liệu hay lệnh thường dưới dạng văn bản đọc được, không có các biến chứa chiều

dài hay checksum của dữ liệu FTP, SMTP là các giao thức loại này

Fuzz các giao thức phức tạp: thường gồm dữ liệu nhị phân cùng với các xâu

kết hợp lại Cơ chế xác thực thường yêu cầu một vài hình thức mã hóa và các trạng thái giao thức phức tạp

Fuzzer ứng dụng Web: Ứng dụng web đang dần trở nên thông dụng và thuận tiện

cho người dùng trong việc truy cập các dịch vụ đầu cuối như email, thanh toán trực tuyến Với sự phát triển của Web 2.0, các ứng dụng truyền thống chạy trên PC đang dần chuyển sang Web

Khi fuzzing các ứng dụng Web, nhà nghiên cứu chủ yếu tìm kiếm các lỗi đặc trưng như SQL injection, Cross Site Scripting (XSS), Những gì cần thiết của fuzzer là khả năng giao tiếp theo giao thức HTTP, thu nhận dữ liệu phản hồi và phân tích

Một vài fuzzer loại này là: WebScarab, SPI Fuzzer và Codenomicon HTTP Test

Suite

Fuzzer trình duyệt web: Thực chất đây là một hình thức fuzz định dạng tệp, mục

tiêu là các trình duyệt web Do tính thông dụng của của các ứng dụng Web nên người ta chia nó ra thành một loại riêng Fuzzer trình duyệt web không chỉ hạn chế

ở các thẻ HTML, mà còn tìm lỗi trong việc phân tích các thẻ CSS, các thành phần COM COMRaider là công cụ xuất sắc trong việc fuzzing các thành phần

Trang 35

COM/ActiveX Các công cụ fuzzing loại này phải kể đến mangleme, DOM-Hanoi, Hamachi, CSSDIE, COMRaider

2.5.3 Fuzzer trong bộ nhớ (In-memory fuzzer)

Đôi khi trong quá trình kiểm tra có một vài khó khăn làm cản trở việc fuzzing Thí dụ cần fuzz một trường của giao thức, nhưng trường này lại được mã hóa một cách phức tạp trong gói tin mà việc mô phỏng gói tin như vậy khá phức tạp, người nghiên cứu muốn bỏ qua công đoạn mã hóa và giải mã, đó là lúc cần đến In-Memory fuzzer Ý tưởng của loại fuzzer này khá đơn giản, nhưng việc cài đặt không đơn giản chút nào Một cách tiếp cận là tạm dừng tiến trình đích cần fuzzing lại, chèn dữ liệu vào đúng hàm cần kiểm tra, khôi phục lại trạng thái của tiến trình với dữ liệu mới, lặp đi lặp lại đến khi hết bộ dữ liệu

Fuzzer loại này có những ưu điểm điểm sau:

Tốc độ fuzzing cao: Dữ liệu chèn trực tiếp vào bộ nhớ, những đoạn chương trình

không cần thiết được bỏ qua nên tốc độ tăng đáng kể nhất là với các giao thức mạng

Nhanh đến đoạn chương trình cần kiểm tra: Đôi khi một vài giao thức cần thực

hiện thao tác nén hoặc mã hóa hoặc tính toán checksum Thay vì tạo ra fuzzer phải sinh dữ liệu chính xác để vượt qua được các thao tác trên, In-Memory có thể chèn trực tiếp nội dung cần fuzz ngay sau khi chương trình giải nén, giải mã hoặc thực hiện tính checksum

Nhược điểm của loại fuzzer này cũng không ít:

Dự đoán sai: Bởi vì dữ liệu thô được chèn trực tiếp vào bộ nhớ của ứng dụng, có

thể có trong thực tế điều đó không bao giờ xảy ra so với truyền dữ liệu vào chương trình một cách chính thống

Trang 36

Khó mô phỏng lại: Trong trường hợp phát hiện lỗi, người nghiên cứu cũng phải

bằng cách nào đó mô phỏng được trường hợp xảy ra lỗi trong thực thế, không phải trực tiếp chèn vào bộ nhớ, quá trình này khá tốn thời gian và phức tap

Độ phức tạp cao: Phương pháp này cực kỳ phức tạp để cài đặt thành chương trình

hoàn chỉnh

2.5.4 Fuzzing framework

Fuzzing framework thực chất là những fuzzer rất chung chung, hoặc các thư viện hỗ trợ việc biểu diễn dữ liệu cho nhiều loại ứng dụng Thường Fuzzing framework bao gồm thư viện để sinh ra các xâu hoặc giá trị thường gây lỗi sẵn cho chương trình

fuzzer Đồng thời nó cũng gồm các công cụ hỗ trợ cho việc truyền dữ liệu qua mạng hoặc ghi vào tệp Một số fuzzing framework có sẵn như: SPIKE, Peach,

Fuzzing Framework có ưu điểm sau :

Tính tái sử dụng cao: Một fuzzing framework thực sự sẽ có thể được dùng cho

nhiều ứng dụng đa dạng khác nhau

Phát triển bởi cả cộng đồng: Một dự án với tính mở sẽ được chào đón bởi cộng

đồng, trong trường hợp này mỗi giao thức, mỗi định dạng sẽ được cộng đồng phát triển và bổ sung vào framework cho hoàn thiện hơn, đa dạng hơn

Nhược điểm của Fuzzing Framework :

Phức tạp cho người sử dụng: Khó khăn này chỉ là bước đầu khi ta phải tìm hiểu

và sử dụng được cả một framework lớn, có quá nhiều tính năng

Thời gian phát triển: Việc thiết kế và phát triển một Fuzzing framework so với

thiết kế một ứng dụng fuzzing cho những giao thức cụ thể đòi hỏi nhiều thời gian

và công sức hơn

Trang 37

2.6 Các bước của Fuzzing

Quá trình fuzzing phụ thuộc vào nhiều yếu tố, do đó cách tiếp cận có thể rất khác nhau, hoàn toàn phụ thuộc vào ứng dụng cần kiểm tra, kĩ năng của người nghiên cứu Tuy vậy có thể chia làm các bước cơ bản [11] sau

1 Xác định phần mềm và dữ liệu đầu vào

Gần như tất cả các lỗi khai thác được đều do ứng dụng chấp nhận dữ liệu vào của người dùng và xử lý mà không kiểm tra đầy đủ tính đúng đắn của dữ liệu Liệt kê hết được các khả năng, đầu vào của dữ liệu là nhân tố quyết định sự thành công của fuzzing

2 Sinh dữ liệu fuzzing

Khi đã xác định được đầu vào, việc quyết định sử dụng intelligent fuzzing hay dumb fuzzing là tùy thuộc vào mục tiêu và định dạng dữ liệu Quá trình sinh này nên được thực hiện tự động, mang tính kinh nghiệm của người phát triển các bộ sinh dữ liệu

3 Gửi dữ liệu cho ứng dụng

Quá trình này có thể thực hiện bằng tay hay tự động, có thể là tự động gửi gói tin đến giao thức mạng cần fuzz, hoặc mở một file Tuy nhiên việc này nếu thực hiện tự động được là tốt nhất

4 Theo dõi lỗi và phân tích

Trong bước này, đòi hỏi các kĩ thuật giám sát các hành vi của phần mềm khi xử lý dữ liệu Khi lỗi được phát hiện, tùy theo mức độ mà ta có thể đánh giá được khả năng bị khai thác của lỗi, càng dễ khai thác thì càng

Trang 38

nguy hiểm Thêm vào đó, ghi log trong quá trình fuzzing là một yêu cầu bắt buộc để tìm ra module gây lỗi của phần mềm

2.7 Hạn chế của Fuzzing

Các lỗi logic: Một vài ứng dụng cần những quyền đặc biệt của user mới có thể thực

thi các chức năng nào đó Thí dụ hệ thống quản lý công việc trực tuyến, cho phép người dùng truy cập từ xa thông qua trình duyệt Những người dùng đặc biệt, chẳng hạn quản trị, có quyền truy nhập đến những chắc năng như thêm/xóa công việc, trong khi người dùng thông thường chỉ có quyền xem Lúc đó, Fuzzer không thể nào biết được khu vực nào, tính năng nào có thể truy cập được bởi người quản trị Việc cài đặt ứng dụng fuzzer hiểu được điều này là hoàn toàn có thể song sẽ cực kỳ

phức tạp

Hiệu quả không cao khi có ít thông tin về mục tiêu: Đối với một Fuzzer, khi có

rất ít thông tin về mục tiêu, chương trình sẽ không thể làm gì hơn được ngoài việc gửi dữ liệu đến Thí dụ chúng ta cần fuzzing một giao thức nào đó và đầu tiên cần đăng nhập để có thể tiếp tục fuzz các lệnh khác, nhưng nếu không có đủ thông tin

để biết liệu quá trình đăng nhập có thành công hay không, cũng như không biết liệu câu lệnh gửi đi có đến được được đoạn chương trình ứng dụng xử lý lệnh đó không,

phạm vi fuzzing sẽ hạn chế đi rất nhiều

Các lỗi về hư hỏng bộ nhớ: Việc bộ nhớ bị phá hủy bởi dữ liệu fuzz thường được

ghi nhận bởi các ngoại lệ (exception), tuy vậy nếu ứng dụng bắt và xử lý các ngoại

lệ cẩn thận và không có trình gỡ rối nào gắn vào ứng dụng, sẽ rất khó để fuzzer phát

hiện được có lỗi hay không

Lỗi đa cấp: Khai thác một hệ thống thông thường không chỉ tấn công vào một

điểm yếu là đủ, có thể cần đến sự kết hợp của nhiều lỗi lại Fuzzing thường chỉ hữu ích khi phát hiện một điểm yếu riêng biệt chứ không có khả năng liên tiếp tấn công

Trang 39

2.8 Các vấn đề trong fuzzing

2.8.1 Sinh dữ liệu

Đây là một trong những vấn đề khá gai góc trong fuzzing Bộ sinh dữ liệu tốt phải đảm bảo dữ liệu sinh ra phải bao trùm được các khả năng của đầu vào Nếu có quá nhiều dữ liệu thừa được sinh ra, sẽ ảnh hưởng không tốt tới hiệu năng fuzzing Điều này có thể được minh chứng qua phương pháp dump fuzzing

Hiện nay, cũng đã có một số phương pháp nhằm tăng hiệu quả trong sinh dữ liệu

fuzzing Sau đây, xin giới thiệu hai phương pháp khá hay

a Phương pháp sử dụng cơ chế phản hồi từ debugger

Hình 16: Fuzzing với cơ chế phản hồi từ debugger

Trong mô hình fuzzing cổ điển, phản hồi từ debugger về fuzzer chỉ đơn thuần là thông báo về tình trạng của phần mềm mục tiêu sau mỗi lần lặp fuzzing, không hề có thông tin kèm theo nào hỗ trợ việc sinh dữ liệu hiệu quả

Trang 40

Cơ chế sử dụng phản hồi từ debugger này nảy sinh ra từ nhận xét: “việc sinh ra các test case cho tất cả các trường của một file format, một protocol là không cần thiết” Bởi vì

có những thành phần dữ liệu có thể được coi là "vô hại"; nhưng cũng có những thành phần lại được đưa vào xử lý bởi những hàm "khá nguy hiểm" như: strcpy(), printf(), Autodafé là một fuzzer có cách xử lý khá thông minh khi lợi dụng điều này Các thành phần dữ liệu được Autodafe coi là các marker, với các trọng số tương ứng Trọng số của marker sẽ tăng lên khi bị phát hiện rằng nó đã được truyền tới hàm API nguy hiểm Marker với trọng số cao hơn sẽ được xét thêm mức ưu tiên và fuzz trước Khi debugger phát hiện ra các lỗi, nó liền thông báo cho fuzzer, test case cũng sẽ được lưu lại Bằng việc xét mức ưu tiên các biến có thể fuzz và bỏ qua các trường hợp không bao giờ được truyền tới hàm API nguy hiểm, phần dữ liệu fuzzing có thể giảm khá nhiều

b Phương pháp sử dụng thực thi hình thức (symbolic execution)

Thực thi hình thức là thuật ngữ dùng để chỉ việc phân tích chương trình bằng việc theo dõi các kí hiệu của biến hơn sử dụng các giá trị thực của nó

Thực thi hình thức có thể được dùng để suy ra tất cả các đầu vào mà chương trình sẽ nhận Ta có thể thấy điều này qua ví dụ sau đây:

Ngày đăng: 25/07/2017, 21:38

TỪ KHÓA LIÊN QUAN

TÀI LIỆU CÙNG NGƯỜI DÙNG

TÀI LIỆU LIÊN QUAN

w