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

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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

1


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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

2


MỤC LỤC
LỜI CAM ĐOAN

1

LỜI CẢM ƠN

2

MỤC LỤC

3

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

6

MỞ ĐẦU

8

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

9

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

12

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

12

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

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

14
15

1.1.1.

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

18

1.1.2.

Lỗ hổng tràn số nguyên

19

1.1.3.

Lỗ hổng format string

20

1.2.

Kiểm thử bảo mật

22

1.2.1. Khái niệm

22

1.2.2. Các thuật ngữ

22

Kết chương

25

1.3.

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

26

2.1.

Khái niệm

27

2.2.

Lịch sử của Fuzzing

28

2.3.

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

29

2.4.

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

31

2.5.

Phân loại Fuzzer

33

2.5.1. Fuzzer cục bộ (Local fuzzer)

33

2.5.2. Fuzzer từ xa (Remote fuzzer)

34

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

35

2.5.4. Fuzzing framework

36

2.6.

Các bước của Fuzzing

37

2.7.

Hạn chế của Fuzzing

38

2.8.

Các vấn đề trong fuzzing

39

2.8.1. Sinh dữ liệu
Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

39
3


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

41

2.8.3. Tăng hiệu suất với fuzzing phân tán

42

2.9.

Kết chương

CHƯƠNG III: XÂY DỰNG HỆ THỐNG FUZZING TRÌNH DUYỆT
3.1.

Trình duyệt

43
44
45

3.1.1.

Tổng quan

45

3.1.2.

Trình duyệt hoạt động như thế nào?

46

3.1.3.

Các thành phần của trình duyệt

48

3.1.4.

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

50

3.2.

Bài toán Fuzzing trình duyệt

52

3.2.1. Mô hình Fuzzing có thể đơn giản hơn, mang tính phân tán sẵn

52

3.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.3. Dữ liệu Fuzzing khá đa dạng

57

3.2.4. Ý tưởng cải tiến cơ chế sinh dữ liệu Fuzzing

60

3.3.

Đề xuất phương pháp xây dựng hệ thống Fuzzing trình duyệt

3.3.1.

Thiết kế ngôn ngữ mô tả dữ liệu fuzzing

61
61

3.3.2. Thiết kế chức năng hệ thống

75

3.3.3. Thiết kế kiến trúc hệ thống

76

3.4.

Một số hình ảnh về hệ thống

85

3.5.

Kết chương

87

CHƯƠNG IV: THỬ NGHIỆM VÀ ĐÁNH GIÁ

88

4.1.

Các tiêu chí đánh giá

89

4.2.

Tính sử dụng

89

4.3.

Khả năng phát hiện lỗ hổng

91

4.3.1. Với các lỗ hổng đã biết

91

4.3.2. Với các lỗ hổng chưa biết

93

4.4.

Hiệu suất

93

4.4.1. Phương pháp tiến hành

94

4.4.2. Kết quả

94

Đánh giá

96

4.5.

KẾT LUẬN
A.

Kết luận

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

97
97

4


B.

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

THAM KHẢO

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

98
99

5


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
Hình 41: Biểu đồ phân rã chức năng ......................................................................................75
Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

6


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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

7


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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

8


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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

9


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
loại “zero-day”, vốn có mặt trong mọi phiên bản hệ điều hành Windows khi đó.
Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

10


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.
Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

11


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.
Cơ sở khoa học và thực tiễn của đề tài:
Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

12


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ý

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

13


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

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

14


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.

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

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)

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)

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

16


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.

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

17

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:

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

18


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

// ...
char buffer[5];
memcpy(buffer, argv[1]);
// ...
}

Mảng buffer ở trên chỉ được cấp phát 5 phần tử char và được dùng để lưu tạm tham số
truyền vào cho chương trình. Nếu tham số truyền vào có độ dài nhỏ hơn 5, mọi chuyện
vẫn ổn. Tuy nhiên, nếu ta nhập vào tham số với độ dài lớn hơn 5, sẽ gây ra lỗi thực thi
và khiến chương trình đổ vỡ.
1.1.2. Lỗ hổng tràn số nguyên
Các số nguyên có độ dài cố định (8 bit, 16 bit, 32 bit, ...), vì thế nó chỉ có thể dữ một
giá trị lớn nhất nào đó. Khi lưu một giá trị lớn hơn ngưỡng đó, hiện tượng tràn số
nguyên sẽ xảy ra. Theo chuẩn ISO C99, tràn số nguyên gây ra các hành vi không xác
định: trình biên dịch có thể không làm tròn số hoặc thoát hẳn chương trình ...
Lỗi tràn số nguyên không thể bị phát hiện cho tới khi nó diễn ra. Không có cách nào
cho một ứng dụng xác định rằng một kết quả được tính toán trước đó có đúng hay
không. Điều này có thể vô cùng nguy hiểm nếu như tính toán đó làm việc với kích cỡ
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[]){
unsigned short s;

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

19

int i;
char buf[80];
if(argc < 3)
return -1;
i = atoi(argv[1]);
s = i;
if(s >= 80){ // w1
printf("Oh no you don't!\n");
return -1;
}
printf("s = %d\n", s);
memcpy(buf, argv[2], i);
buf[i] = '\0';
printf("%s\n", buf);
return 0;
}

Độ dài của tham số truyền vào cho chương trình được truyền vào từ dòng lệnh và giữ
trong số nguyên i. Khi giá trị này được chuyển đổi thành kiểu short, nó bị cắt cụt
(truncated) nếu như giá trị đó quá lớn để chứa vào s (ví dụ, nếu i là 65536 chẳng hạn).
Bởi vì thế, hoàn toàn có thể vượt qua được bước kiểm tra biên tại [w1] và gây tràn bộ
đệm.
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
con người).

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

20




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:
Mô tả

Hàm format
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
Hình 6: Các hàm Format

Tham số

Đầu ra

Kiểu truyền

%%

Ký tự %

Tham chiếu

%d

Số dạng thập phân

Tham trị

%c

Ký tự

%x

Số dạng lục thập phân

Tham trị

%s

String

Tham chiếu
Hình 7: Các tham số format

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():

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

21


int main(int argc, char **argv){
char buf[128];
...
snprintf(buf,128,argv[1]);
}

Kẻ tấn công có thể truyền tham số đầu vào chứa các tham số format như %x.

Hàm snprintf() sẽ coi như đó là một chuỗi format và sẽ sử dụng các tham số đi
kèm để trả về kết quả ở bộ đệm. Tuy nhiên, vì không có tham số nào được cung
cấp, nên ở đây sẽ xảy ra một lỗi truy cập bộ nhớ trái phép (Memory Access
Violation) và có thể bị khai thác.
1.2. Kiểm thử bảo mật
1.2.1. Khái niệm
Theo Wikipedia, kiểm thử bảo mật (Security testing) là quá trình để xác định tính an
toàn của một hệ thống thông tin trong bảo vệ dữ liệu và hoạt động theo đúng những gì
đã đượ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ỗ

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

22


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 …

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

23


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.

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

24


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.

Học viên thực hiện: Lê Đức Anh Lớp 11BMTTT Khóa học 2011B

25