Pentest Methodology part 1

Chương 21 Phương pháp Pentest Chương này trình bày phương pháp chi tiết từng bước phương pháp tấn công một ứng dụng web, gồm các loại lỗ hổng và kỹ thuật tấn công được trình bày trong các chương trước[.]

Chương 21 Phương pháp Pentest

Chương này trình bày phương pháp chi tiết từng bướcphương pháp tấn công một ứng dụng web, gồm các loại lỗ hổng

và kỹ thuật tấn công được trình bày trong các chương trước Tuyrằng phương pháp này không giúp tìm ra tất cả các lỗ hổng ứngdụng nhất định nhưng sẽ đảm bảo được rằng kiểm thử tất cả khuvực cần thiết trên ứng dụng và đảm bảo tìm thấy nhiều vấn đềnhất với tài nguyên hiện có

Hình 1 dưới đây minh họa các công việc chính mà phươngpháp luận này mô tả Chương này sẽ bám sát sơ đồ và chia nhỏnhiệm vụ liên quan Số thứ tự tương ứng trong sơ đồ là thứ tự cácbước trong phương pháp luận

Phương pháp luận được trình bày dưới dạng một chuỗi cácnhiệm vụ được tổ chức và sắp xếp phụ thuộc lẫn nhau Trongphương pháp, sự phụ thuộc này được nêu trong mô tả nhiệm vụ.Tuy nhiên trong thực tế, người kiểm thử sẽ thường xuyên phải đưa

ra quyết định về hướng đánh giá của mình theo các trường hợp cụthể Ví dụ:

- Thông tin thu thập được tại một thời điểm nào đó có thểkhiến bạn quay lại bước trước đó để hình thành các cuộctấn công tập trung hơn Ví dụ: một lỗi kiểm soát truy cậpcho phép liệt kê danh sách người dùng để thực hiện cáccuộc tấn công các chức năng xác thực

- Việc phát hiện lỗ hổng chính trong chức năng nào đó củaứng dụng giúp bỏ qua một hoặc một vài giai đoạn kiểmtra ở chức năng khác Ví dụ: lỗ hổng lộ mã nguồn chươngtrình cho phép đánh giá chức năng chính của ứng dụngtheo hướng white box thay vì black box như thường lệ

- Kết quả kiểm tra ở một chức năng nào đó giúp phát hiệnmột lỗ hổng nhất định ở chức năng khác để chuyểnhướng kiểm thử Ví dụ: một lỗi chung trong bộ xác thựcđầu vào giúp việc tìm cách bỏ qua các biện pháp phòngthủ của ứng dụng nhanh chóng.

Hình 1.0 Các công việc chính của phương pháp luậnQuy trình trong phương pháp luận này giúp cho công việckiểm thử tránh khỏi các sơ suất không đáng có, nhưng không bắtbuộc tuân thủ cứng nhắc Các nhiệm vụ được mô tả trong phươngpháp luận này phần lớn là tiêu chuẩn và chính thống, các cuộc tấncông có thể không chỉ có như vậy

Hướng dẫn chung

Khi thực hiện kiểm thử ứng dụng web, người kiểm thử cầntuân thủ một số lưu ý chung, có thể áp dụng cho tất cả các khuvực, chức năng khác nhau và các ký thuật cần thực hiện

Một số ký tự được coi là đặc biệt trong HTTP request và sẽđược encode Khi sửa đổi nội dung request, cần sử dụng URLencode các ký tự này để đảm bảo chúng diễn giải đúng ý nghĩa:

- & được dùng để phân tách các tham số trong chuỗi truyvấn URL và nội dung message Để chèn một ký tự & cầnencode thành %26

- = được dùng để phân tách tên và giá trị tham số trongchuỗi truy vấn và nội dung message Để chèn một ký tự

- + là encode của khoảng trắng nên để chèn ký tự + cầnencode thành %2b

- ; được dùng để tách các cookie riêng lẻ trong Cookieheader Để chèn ký tự ; cần encode thành %3b

- # được dùng để đánh dấu các phân đoạn URL Nếu nhập

ký tự này vào URL, nó giúp cắt bớt URL gửi đến máy chủ

Hơn nữa, việc nhập dữ liệu URL encode vào một form sẽkhiến trình duyệt thực hiện một lớp encode khác Ví dụ, khi gửi

%00 trong form được kết quả encode cuối cùng thành %2500 gửiđến máy chủ Vì lý do này, thông thường nên sử dụng proxy chặnbắt các request

Trong nhiều trường hợp kiểm thử, người kiểm thử cần thựchiện gửi các chuỗi tạo thủ công, theo dõi phàn hồi của ứng dụng

để tìm các điểm bất thường từ đó phát hiện lõ hổng bảo mật.Trong một số trường hợp, phản hồi của ứng dụng với một request

cụ thể chứa dấu hiệu của lỗ hổng bất kể lỗ hổng đã được kíchhoạt hay chưa Trong mọi trường hợp khi đầu vào cụ thể dẫn đếnhành vi bất thường, cần kiểm tra lại xem việc gửi request lànhtính có gây ra kết quả tương tự hay không Nếu có, không thể kếtluận đó là một lỗ hổng bảo mật

Các ứng dụng thường tích lũy trạng thái từ các requesttrước đó gây ảnh hưởng đến việc phản hồi các request khác Đôikhi, muốn khai thác một lỗ hổng dự kiến và xác định nguyên nhâncủa các hành vi bất thường cần phải loại bỏ ảnh hưởng của cáctrạng thái tích lũy Để làm được điều đó, thông thường chỉ cần bắtđầu một phiên làm việc mới, điều hướng đến điểm bất thườngbằng các request lành tính sau đó khai thác thác lại Thôngthường, có thể lặp lại bước refresh này bằng cách điều chỉnh cácphần của cookie request container và thông tin bộ nhớ đệm.ngoài ra, có thể sử dụng công cụ Burp Repeater để cô lập request,thực hiện điều chỉnh và gửi lại request nhiều lần

Một số ứng dụng sử dụng cân bằng tải trong đó HTTPrequest liên tiếp có thể được xử lý bởi các máy chủ khác nhau

Các máy chủ này có thể có những khác biệt nhỏ về nội dung cấuhình ảnh hưởng đến kết quả khai thác Ngoài ra, một số cuộc tấncông thành công dẫn đến thay đổi trạng thái máy chủ chẳng hạnnhư tạo file mới Để phân biệt các ảnh hưởng, người kiểm thử cóthể phải thực hiện gửi liên tiếp request giống hệt nhau, kiểm trakết quả của từng request cho đến khi nhận được kết quả từ máychủ liên quan.

Khi triển khai kiểm thử ứng dụng web, người kiểm thử phảixác định chính xác tên máy chủ, URL, các chức năng được sửdụng và các hạn chế đối với đội ngũ kiểm thử Người kiểm thửcũng cần cho chủ sở hữu nhận thức chính xác các rủi ro liên quanđến việc thực hiện kiểm thử xâm nhập Khuyên chủ sở hữu saolưu mọi dữ liệu quan trọng trước khi bắt đầu công việc

1 Xác định chức năng ứng dụng

Hình 1.1 Xác định các chức năng ứng dụng

1.1 Xác định chức năng hiển thị (Explore Visible Content)

Cấu hình để trình duyệt sử dụng proxy / spidering tool CảBurp và WebScarab đều có thể sử dụng để giám sát và phân tíchnội dung trang web đươc chặn bởi pproxy

Có thể cấu hình trình duyệt sử dụng tiện ích mở rộng nhưIEWatch để theo dõi và phân tích nội dung HTTP va HTML đangđược trình duyệt xử lý.

Sử dụng ứng dụng bình thường, truy cập mọi liên kết vàURL, hoàn thành tất cả các form và các chức năng nhiều bước.Thử với JavaScript được cho phép và chặn cũng như cookie đượccho phép và chặn nhiều ứng dụng có thể xử lý các cấu hình trìnhduyệt khác nhau, người dùng có thể truy cập nội dung đường dẫn

mã nguồn khác nhau trong ứng dụng

Nếu ứng dụng sử dụng xác thực, có thể yêu cầu chủ sở hữucung cấp tài khoản hoặc tạo tài khoản, sử dụng tài khoản này đểtruy cập các chức năng được bảo vệ

Khi kiểm tra, theo dõi các request và response bị proxychặn lại để hiểu dữ liệu nào đang được trao đổi và cách ứng dụngphía client sử dụng để kiểm soát hành vi ứng dụng phía máy chủ

Kiểm tra lại kiến trúc trang web được tạo bởi các công cụspider và xác định các nội dung và chức năng chưa được dùng(kiểm tra) qua Từ kiến trúc trang web xác định vị trí chức năngchưa được kiểm tra (ví dụ: trong Burp Spider, kiểm tra LinkedFrom details) Truy cập từng chức năng bằng trình duyệt để spiderphân tích cú pháp phản hồi của máy chủ để xác định các thànhphần khác Lặp lại bước này cho đến khi không xuất hiện thànhphần chức năng nào khác

Khi đã duyệt web theo cách thủ công và thụ động, ngườikiểm thử có thể chủ động thu thập thông tin ứng dụng bằng cáccông cụ quét với từng URL đã biết bước này có thể làm xuất hiệncác nội dung bổ sung khi thu thập thông tin theo cách thủ công.Trước khi thực hiện thu thập thông tin thủ công, cần xác định các

URL có thể phá vỡ phiên ứng dụng, loại chúng khỏi phạm vi kiểmtra.

1.2 Consult Public Resources (sử dụng nguồn công khai)

Sử dụng các công cụ tìm kiếm trên internet (như WaybackMachine) để xác định các nội dung công khai của đối tượng

Sử dụng các tùy chọn tìm kiếm nâng cao để cải thiện hiệu

quả kiểm tra Ví dụ: trên Google, dùng site: để truy xuất tất cả kết quả cho đối tượng, link: truy xuất các trang khác liên kết đến đối

tượng Nếu kết quả tìm kiếm không còn xuất hiện đối với ứngdụng hiện tại thì vẫn có thể xem trong cache của công cụ tìmkiếm nội dung này có thể chứa các liên kết đến tài nguyên bổsung chưa bị xóa

Thực hiện tìm kiếm bất kỳ tên, địa chỉ email nào xuất hiệntrong nội dung ứng dụng, chẳng hạn như thông tin liên hệ baogồm cả thông tin không hiển thị như HTML comment Ngoài ra,cần tìm kiếm trên các nhóm và kênh tin tức tìm kiếm bất kỳ chitiết kỹ thuật nào liên quan đến mục tiêu và cơ sở hạ tầng hỗ trợcủa nó được đăng tải trên các diễn đàn

Xem lại các tệp WSDL (Web Service Description Language)

để tạo danh sách hàm và các tham số mà ứng dụng có thể sửdụng

1.3 Tìm kiếm các chức năng ẩn (Discover Hidden Content)

Xác định cách ứng dụng xử lý request liên quan đến cácmục không tồn tại thực hiện một số request thủ công đối với cáctài nguyên hợp lệ và không hợp lệ, so sánh các response của máychủ để xác định khi nào một đối tượng không tồn tại

Xác định danh sách các thư mục, file phổ biến và phần mởrộng tên tệp phổ biến thêm vào danh sách các tên tồn tại và các

tên được suy ra Xác định quy ước đặt tên của nhà phát triển ví

dụ: nếu có các trang AddDocument.jsp và ViewDocument.jsp thì cũng có thể có trang EditDocument.jsp và RemoveDocument.jsp.

Kiểm tra code phía client để xác định các manh mối về chứcnăng ẩn của máy chủ như HTML comment hay các thành phầnform bị vô hiệu hóa

Sử dụng các kỹ thuật tự động hóa được mô tả trong chương

14, thực hiện hàng loạt request với các thư mục, file và phần mởrộng file, theo dõi phản hồi của máy chủ để xác định các thưmục/file tồn tại và có khả năng truy cập

Thực hiện lặp lại các bước thu thập thông tin này với cácchức năng khác nhau

1.4 Tìm kiếm thành phần mặc định

Chạy Nikto để xác định các nội dung mặc định Sử dụng các

tùy chọn Nikto để tối đa hóa hiệu quả Ví dụ: sử dụng –root để chỉ định thư mục/khu vực được kiểm tra nội dung mặc định hoặc -404

chỉ định một chuooixdaanx đến trang thông báo lỗi File Not Found

Kiểm tra lại kết quả băng phương pháp thủ công, loại bỏkết quả giả

Request đến thư mục, chỉ định IP Host header, xác định xem

ứng dụng có phản hồi không, nếu có, chạy Nikto với IP này nhưmáy chủ

Request đến thư mục, chỉ định danh sách User-Agent

www.useragentstring.com/pages/useragentstring.php

1.5 Liệt kê các chức năng được định danh

Xác định các hàm được truy cập bằng định danh (ví dụ:

/admin.jsp?action=editUser hay /main.php?func=A21).

Áp dụng các kỹ thuật trong mục 1.3 đối với từng chức năngriêng lẻ ví dụ: nếu ứng dụng sử dụng tham số chứa tên hàm.Trước tiên, xác định hành vi ứng dụng khi tên hàm không hợp lệ

và hợp lệ xác định danh sách tên hàm phổ biến hoặc chu trìnhthông qua phạm vi cú pháp của các định danh đang sử dụng thửliệt kê các chức năng hợp lệ tự động

Xây dựng kiến trúc ứng dụng dựa trên đường dẫn chức năngthay vì URL Kiểm tra các chức năng, luồng logic và sự phụ thuôcgiữa chúng (xem chương 4)

1.6 Kiểm tra các thông số debug (Test for Debug Parameters)

Chọn các trang/chức năng có khả năng chứa các tham sốdebug ẩn (chẳng hạn debug = true) Chúng có khả năng xuấthiện trong các chức năng chính như đăng nhập, tìm kiếm, tải lênhoặc tải xuống

Sử dụng danh sách tham số gỡ lỗi phổ biến (như debug,test, hide, source) và các giá trị chung (như true, yes, on, 1) Đốivới mỗi cặp tên tham số/giá trị Gửi từng cặp cho mỗi hàm mụctiêu Đối với POST request, cấp tham số trong cả truy vấn URL vànội dung request Sử dụng các kỹ thuật được mô tả trong chương

14 để thực hiện tự động hóa Ví dụ: sử dụng tấn công bomb trongBurp Intruder để kết hợp tất cả các hoán vị của payload

Kiểm tra các phản hồi bất thường của ứng dụng để xác địnhcác trường hợp mà thông số thêm vào có ảnh hưởng đến quá trình

xử lý của ứng dụng

Xác định các cơ chế bảo mật cốt lõi được ứng dụng sử dụng

và cách chúng hoạt động Hiểu các cơ chế xác thực, quản lý phiên

và kiểm soát truy cập và các chức năng hỗ trợ chúng, chẳng hạnđăng ký người dùng và khôi phục tài khoản

Xác định các chức năng và hành vi rộng hơn, chẳng hạnchuyển hướng, liên kết ngoài, thông báo lỗi và các chức năngquản trị, ghi nhật ký

Xác định các chức năng khác với giao diện GUI tiêu chuẩn,đặt tên tham số hoặc cơ chế điều hướng được sử dụng ở những vịtrí khác, chọn để kiểm tra chuyên sâu

2.2 Xác định đầu vào dữ liệu

Xác định tất cả các vị trí người dùng đưa dữ liệu vào quátrình xử lý của ứng dụng như URL, tham số truy vấn, POST data,cookie và các HTTP header khác được ứng dụng xử lý

Kiểm tra các cơ chế mã hóa hoặc truyền dữ liệu tùy chỉnhđược ứng dụng sử dụng, ví dụ như định dạng chuỗi truy vấn không

chuẩn xem xét các dữ liệu gửi đi có gồm tên và các giá trị tham

số không hoặc phương tiện biểu diến thay thế có được sử dụngkhông

Xác ddnhj các kênh ngoài băng tần mà thông qua đó ngườidùng có thể kiểm soát dữ liệu của bên thứ 3 khác được đưa vàoquá trình xử lý dữ liệu của ứng dụng ví dụ: ứng dụng web mail xử

lý và hiển thị các message nhận được qua SMTP

2.3 Xác định công nghệ sử dụng

Xác định các công nghệ khác nhau được sử dụng phía máykhách, chẳng hạn form, scripts, cookie, Java Applets, ActiveXcontrols, đối tượng Flash

Xác định công nghệ đang sử dụng phía máy chủ, gồm ngônngữ kịch bản, nền tảng ứng dụng, cách tương tác với các thànhphần back-end như cơ sở dũ liệu và email hệ thống (nếu có thể)

Kiểm tra các tiêu đề HTTP server được trả về trong cácresponsese, đồng thời kiểm tra các mã nhận dạng phần mềmkhác tồn tại trong các tiêu đề HTTP tùy chỉnh hoặc comment trong

mã nguồn HTML Các khu vực khác nhau của ứng dụng có thểđược xử lý bởi các thành phần backend khác nhau vì vậy có thểnhận được kết quả khác nhau

Chạy công cụ Httprint để xác định chính xác máy chủ web.Kiểm tra lại kết quả xác định kiến trúc ứng dụng để xác địnhcác phần mở rộng tệp, thư mục hoặc URL có thể cung cấp manhmối về công nghệ đang sử dụng trên máy chủ Kiểm tra sessiontoken và cookie Sử dụng Google để tìm kiếm các công nghệ liênquan

Xác định các tập lệnh chứa các chuỗi tham số truy vấnthuộc thành phần code của bên thứ ba tìm kiếm trên Google

bằng cách sử dụng inurl: Thực hiện đánh giá sơ bộ các trang web

này để xác định các nội dung và chức năng bổ sung không đượclên kết rõ ràng trên ứng dụng (nếu có)

2.4 Xây dựng kế hoạch khai thác

Cố gắng xác định chắc chắn cấu trúc bên trong và chứcnăng của ứng dụng phía máy chủ, các cơ chế được sử dụng đểthực hiện hoạt động tương tác với client Ví dụ: một chức năngxuất đơn đặt hàng của khách hàng có thể đang tương tác với cơ

sở dữ liệu

Đối với mỗi chức năng, xác định các loại lỗ hổng phổ biến cóliên quan Ví dụ: các chức năng truyền tải file dễ bị tấn công Pathtraversal, nhắn tin giữa người dùng dễ bị XSS và các chức năng

‘Liên hệ với chúng tôi’ có thể bị chèn STMP Để biết các ví dụ chitiết hãy xem chương 4

Lập kế hoạch tấn công, ưu tiên các chức năng quan trọng

và các lỗ hổng tiềm ẩn nghiêm trọng có liên quan Sử dụng kếhoạch khai thác này cho các bước còn lại của phương pháp luận

3 Kiểm tra kiểm soát phía máy khách

Hình 3.3 kiểm tra kiểm soát phía client

3.1 Kiểm tra việc truyền dữ liệu qua client

Xác đinh tất cả trường hợp form ẩn, cookie và các tham sốURL được dùng để truyền dữ liệu

Xác định mục đích mục đích sử dụng của các trường hợptrên trong logic ứng dụng thông qua ngữ cảnh mà nó xuất hiệncũng như tên và giá trị của nó

Sửa đổi giá trị của các trường theo các cách liên quan đếnvai trò của nó trong chức năng ứng dụng xác định liệu ứng dụng

có xử lý giá trị tùy ý không và thông tin này có thể bị lợi dụng đểcan thiệp vào logic ứng dụng hay phá vỡ các biện pháp kiểm soátbảo mật nào không

Nếu ứng dụng không truyền dữ liệu dạng rõ ràng từ client,người kiểm thử có thể tấn công bằng nhiều cách khác nhau Nếutrường bị làm rối hay encode, hãy giải mã thuật toán trộn/encode

đó để thay thế dữ liệu cần thiết ngay cả khi dữ liệu được mã hóa

an toàn vẫn có thể tấn công phát lại các dữ liệu đó trong các ngữcảnh khác để can thiệp logic ứng dụng xem chương 5 để biếtthêm các ví dụ

Nếu ứng dụng sử dụng ASP.NET ViewState, kiểm tra xem nó

có thể giả mạo hay không hoặc có chứa thông tin nhạy cảm haykhông Tuy nhiên, ViewState có thể dùng khác nhau trên các trangkhác nhau

- Sử dụng trình phân tích ViewState trong Burp Suite đểkiểm tra EnableViewStateMac có được bật hay không,nếu có chứng tỏ không thể sửa

- Giải mã ViewState, kiểm tra xem có chứa dữ liệu nhạycảm hay không

- Sửa đổi một trong số các giá trị tham số rồi mã hóa lạiViewState Nếu ứng dụng chấp nhận giá trị sửa đổi chứng

tỏ có thể coi ViewState như kênh đưa dữ liệu tùy ý vàoquá trình xử lý của ứng dụng thực hiện kiểm tra tương tựđối với toàn bộ dữ liệu của ViewState.

3.2 Kiểm soát đầu vào phía client

Xác định các trường hợp client kiểm soát đầu vào như giớihạn độ dài, kiểm tra JavaScript xác thực thông tin đầu vào trướckhi chúng được gửi tới server Các kiểm soát này có thể bypass đểrequest tùy ý đến server Ví dụ:

Khả năng bỏ qua xác thực phía client chưa hẳn là một lỗhổng tuy nhiên, cần kiểm tra kỹ lưỡng quá trình xác thực đangthực hiện xác định liệu ứng dụng có đang dựa vào kiểm soát phíaclient để bảo vệ ứng dụng khỏi các tấn công từ đầu vào khôngđúng định dạng hay không Đồng thời kiểm tra xem có bất kỳ lỗhổng nào được kích hoạt bởi những đầu vào này hay không

Kiểm tra các form HTML để xác định các thành phần bị vôhiệu, chẳng hạn nút gửi màu xám Ví dụ:

<input disabled=”true” name=”product”>

Nếu có, thử gửi dữ liệu đến server cùng các thông số kháccủa form Xem xét sự ảnh hưởng của chúng đến quá trình xử lýcủa server có thể bị lợi dụng để tấn công Ngoài ra, có thể sửdụng proxy tự động để tự đông vô hiệu hóa các trường, chẳng hạnHTML Modification của Burp Proxy

3.3 Kiểm tra phần mở rộng của trình duyệt

- Hiểu hoạt động của ứng dụng phía client:

o Thiết lập proxy chặn bắt luồng dữ liệu giữa client vàserver Nếu dữ liệu được encode, sử dụng công cụdecode được tích hợp sẵn trong Burp hoặc DserBurp plugin dành cho java

o Xác định các chức năng nhạy cảm, sử dụng cáccông cụ chặn để phát lại request hoặc sửa đổi phảnhồi của máy chủ

- Decompile the Client

o Xác định applet được client sử dụng tìm các loại fileđược request qua proxy: .class, .jar (Java); .swf(Flash); xap (Silverlight) Ngoài ra, có thể tìm đượccác thẻ applet trong mã nguồn HTML ví dụ:

<applet code=”input.class” id=”TheApplet”

codebase=”/scripts/”> </applet>

o Kiểm tra các lệnh gọi đến phương thức của applet từHTML, xác định dữ liệu trả về có gửi đên server haykhông Nếu dữ liệu bị encode/encrypt, có thể phảidịch ngược để lấy mã nguồn

o Tải mã bytecode của applet từ trình duyệt tên filebytecode được chỉ định trong thuộc tính của thẻapplet File sẽ được lưu trong thư mục được chỉ địnhtrong thuộc tính codebase nếu có Nếu không, nó sẽnằm cùng thư mục của trang chứa thẻ applet

o Sử dụng công cụ thích hợp để dịch ngược mãbytecode thành mã nguồn ví dụ:

C:\>jad.exe input.class

Parsing input.class Generating input.jad

Một số công cụ hỗ trợ dịch ngược các thành phần mở rộngtrình duyệt khác nhau:

Java: Jad

Flash: SWFScan, Flasm/Flare

Silverlight: NET Reflector

Nếu applet được nén thành JAR/XAP/SWF, cần giải nén bằngWinRar hoặc WinZip trước

o Kiểm tra lại mã nguồn có liên quan để hiểu quá trình

xử lý đang thực hiện

o Xác định các hàm công khai có thể được ứng dụng

để encode dữ liệu tùy ý của applet

o Nếu không, sửa mã nguồn applet để vô hiệu hóa cácxác thực mà nó thực hiện hoặc để encode đầu vào.Sau đó, biên dịch lại thành định dạng file gốc bằngcách sử dụng các công cụ biên dịch do nhà cung cấpcung cấp

- Attach a Debugger

o Đối với các ứng dụng phía client lớn, thường khódịch ngược toàn bộ ứng dụng, sửa đổi và đóng góilại mà không gặp nhiều lỗi đối với các ứng dụngnày, việc đính kèm trình gỡ lỗi thường nhanh hơn.JavaSnoop giúp thực hiện đối với Java, SilverlightSpy giám sát thời gian chạy của Silverlight client

o Xác định vị trí các chức năng và giá trị chính mà ứngdụng dùng để quản lý logic nghiệp vụ và đặtbreakpoint khi các chức năng mục tiêu được gọi sửađổi đối số hoặc giá trị trả về nếu cần để bypass

- Test ActiveX controls

o Xác định trình điều khiển ActiveX được ứng dụng sửdụng tìm các file cab được request qua proxy hoặccác thẻ object HTML Ví dụ:

o Có thể đoán mục đích của các phương thức ActiveXdựa trên tên và các tham số truyền cho chúng Sửdụng công cụ COMRaider để liệt kê các phươngthức kiểm tra các trường có khả năng dự đoán đểthay đổi hành vi của ứng dụng

o Nếu mục đích của trình điều khiển là thu thập hoặcxác minh thông tin nhất định về client, sử dụng công

cụ Filemon và Regmon để theo dõi các thông tin màtrình điều khiển thu thập được Thường có thể tạocác mục phù hợp trong system registry vàfilesystem để sửa các đầu vào được điều khiển sửdụng và do đó ảnh hưởng đến hành vi của nó

o Kiểm tra ActiveX control để tìm các lỗ hổng có thể bịkhai thác để tấn công người dùng ứng dụng khác

Có thể sửa HTML gọi một hàm để chuyển dữ liệu tùy

ý đến các phương thức và theo dõi kết quả Kiểm tra

các phương thức có tên đặc biệt như LauchExe Cóthể sử dụng COMRaider thực hiện một số kiểm tra

cơ bản đối với ActiveX control để xác định các lỗinhư tràn bộ đệm

Các định vị trí các chức năng liên quan đến xác thực (gồmđăng nhập, đăng ký, khôi phục tài khoản,…)

Nếu ứng dụng không triên khai cơ chế đăng ký tài khoản,xác định cơ chế triên khai cấp tài khoản người dùng

4.2.Kiểm tra chất lượng mật khẩu

Kiểm tra các quy tắc được áp dụng đối với mật khẩu ngườidùng

Sử dụng chức năng đăng ký hoặc thay đổi mật khẩu, đặtnhiều loại mật khẩu yếu khác nhau để xác định các quy tắc đượcthực thi trong thực tế thử với mật khẩu ngắn, chỉ có chữ/số, cácmật khẩu trong từ điển và tên người dùng

Kiểm tra xác thực không đầy đủ Đặt mật khẩu mạnh, thựchiên đăng nhập bằng các biến thể khác nhau của mật khẩu nàynhư thay đổi 1 ký tự, xóa ký tự cuối, xóa ký tự đặc biệt,… nếu thửthành công, cố gắng xác định quá trình xác thực nào đang đượcthực thi

Sau khi thiết lập các quy tắc chất lượng mật khẩu tối thiểu

và mức độ xác thực mật khẩu, xác định phạm vi giá trị khi tấncông dò mật để có xác suất thành công cao Xác định tài khoản cóthể không tuân theo quy định mật khẩu mạnh

4.3 Kiểm tra khả năng liệt kê tên người dùng

Xác định vị trí người dùng gửi username trong các chứcnăng, gồm nhập thông tin trên màn hình, form ẩn hoặc cookie.Các vị trí phổ biến như đăng nhập, đăng ký, thay đổi mật khẩu,đăng xuất, khôi phục tài khoản

Với mỗi vị trí, gửi 2 request, gồm tên người dùng hợp lệ vàkhông hợp lệ kiểm tra reponse của server đối với từng requestgồm mã trạng thái HTTP, chuyển hướng, thông tin hiển thị trên

màn hình, các bất thường trong mã nguồn HTML, thời gian serverphản hồi các thay đổi có thể rất nhỏ (ví dụ: cùng thông báo lỗinhưng khác kiểu chữ, dâu chấm/phẩy) Sử dụng chức năng lịch sửintercept của proxy để kiểm tra traffic WeScarab có chức năng sosánh 2 phản hồi để tìm ra sự khác biệt giữa chúng.

Nếu có sự bất thường, lặp lại kiểm tra đối với cặp giá trịkhác để xác định sự khác biệt làm cơ sở cho việc liệt kê ngườidùng tự động

Kiểm tra nguồn rò rỉ thông tin cho phép liệt kê tên ngườidùng hợp lệ ví dụ: chức năng ghi log, danh sách người dùng đăng

ký thực tế và comment tên/email trong mã nguồn

Xác định các xác thực phụ chấp nhận tên người dùng vàkiểm tra xem nó có sử dụng để liệt kê tên người dùng hay không.Đặc biệt lưu ý đến trang đăng ký cho phép đặc tả tên người dùng

4.4.Kiểm tra khả năng đoán mật khẩu

Xác định vị trí người dùng gửi thông tin đăng nhập haitrường hợp chính thường là đăng nhập và thay mật khẩu chứcnăng thay đổi mật khẩu chỉ thành mục tiêu tấn công nếu có thểdùng bất kỳ username nào

Tại mỗi vị trí, kiểm tra thủ công username hợp lệ nhưngthông tin xác thực không hợp lệ, theo dõi phản hồi của ứng dụng

để xác định sự bất thường sau khoảng 10 lần đăng nhập khôngthành công, nếu ứng dụng không thông báo khóa tài khoản, đăngnhập bằng thông tin xác thực hợp lệ nếu đăng nhập thành công,chính sách khóa tài khoản có thể không hiệu lực

Nếu không có tài khoản hợp lệ, cố gắng liệt kê tên ngườidùng hợp lệ để thử, theo dõi bất kỳ thông báo khóa tài khoản.Tuy nhiên, việc thử này có thể khóa tài khoản người dùng khác

4.5.Kiểm tra chức năng khôi phục tài khoản

Xác định chức năng cho phép ứng dụng khôi phục tài khoảnkhi quên thông tin đăng nhập thường là chức năng Quên mậtkhẩu

Xác định hoạt động của chức năng khôi phục tài khoảnbằng cách thực hiện toàn bộ quy trình khôi phục bằng tài khoảnkiểm soát

Nếu chức năng sử dụng thử thách chẳng hạn như câu hỏi bímật, xác định xem người dùng có thể đặt hoặc chọn thử thách củariêng họ trong khi đăng ký hay không Nếu có, sử dụng danh sáchusername đã liệt kê/thông dụng để thu thập danh sách các thửthách và xem lại danh sách này để xác định tên dễ đoán

Nếu hàm sử dụng gợi ý mật khẩu, hãy thực hiện thu thậpdanh sách các gợi ý mật khẩu và xác định các mật khẩu dễ đoán

Thực hiện tương tự đối với các trường hợp khôi phục tàikhoản đối với tài khoản đã thực hiện tại chức năng đăng nhậpchính để đánh giá lỗ hổng đối với các tấn công brute force

Nếu chức năng liên quan đến gửi e-mail cho người dùng đểhoàn tất quá trình khôi phục, tìm điểm yếu cho phép bạn kiểmsoát tài khoản của người dùng khác Xác định xem có thể kiểmsoát địa chỉ mà e-mail để gửi thông tin khôi phục tài khoản không.Nếu thư chứa URL khôi phục duy nhất, nhận bằng địa chỉ e-mailhợp lệ và xác định khả năng dự đoán URL của người dùng khác

Áp dụng phương pháp được mô tả trong bước 5.3 để dự đoán

4.6.Kiểm tra chức năng “remember me”

Nếu chức năng đăng nhập chính hoặc logic hỗ trợ của nó cóchứa chức năng “Remember me”, sử dụng chức năng này và xácđinh tác dụng của nó Nếu chức năng này cho phép người dùng

đăng nhập vào những lần tiếp theo mà không cần nhập bất kỳthông tin đăng nhập nào, cần kiểm tra xem chức năng này cóchứa lỗ hổng nào không.

Kiểm tra chặt chẽ tất cả các cookie được đặt khi chức năng

“rememer” được kích hoạt Tìm kiếm các dữ liệu nhận dạng ngườidùng có thể dự đoán

Ngay cả khi dữ liệu lưu trữ được encode/encrypt, kiểm tracác thông tin xác thực khác để xác định cơ chế và tìm cáchdecode/decrypt Áp dụng phương pháp được mô tả trong chương5.2 để xác định các dữ liệu đặc biệt

Tùy thuộc kết quả, sửa đổi nội dung cookie theo những cáchphù hợp nhằm cố gắng giả dạng thành những người dùng kháccủa ứng dụng

4.7.Kiểm tra chức năng mạo danh

Nếu ứng dụng chứa bất kỳ chức năng nào cho phép mộtngười dùng mạo danh người khác, kiểm tra kỹ chức năng này xácđịnh các lỗ hổng cho phép mạo danh người dùng tùy ý mà khôngcần được ủy quyền

Kiểm tra các dữ liệu do người dùng cung cấp dùng để xácđịnh người dùng truy cập vào hệ thống cố gắng mạo danh ngườidùng khác đặc biệt là quản trị viên, giúp nâng cao đặc quyền

Nếu thực hiện tấn công mật khẩu tự động (như brute force)lên các tài khoản người dùng khác cần tìm các tài khoản có thể cónhiều hơn 1 mật khẩu hợp lệ hoặc nhiều tài khoản có cùng mộtmật khẩu bởi quản trị viên có thể dùng mật khẩu này để truy cậpứng dụng với bất kỳ người dùng nào

4.8 Kiểm tra tính duy nhất của tên người dùng

Nếu ứng dụng có chức năng tự đăng ký cho phép ngườidùng điền username mong muốn, thử đăng ký hai lần cùng mộtusername với các mật khẩu khác nhau

Nếu ứng dụng chặn lần đăng ký thứ hai, người kiểm thử cóthể khai thác hành vi này để liệt kê các tên người dùng đã đăngký

Nếu ứng dụng đăng ký cả hai tài khoản, xác định hành vicủa ứng dụng khi xảy ra xung đột tên người dùng và mật khẩu Cốgắng thay đổi mật khẩu của một trong các tài khoản để khớp vớimật khẩu của tài khoản kia Ngoài ra, xác định hành vi ứng dụngkhi đăng ký hai tài khoản có tên người dùng và mật khẩu giốnghệt nhau

Nếu ứng dụng cảnh báo hoặc tạo ra lỗi khi xảy ra xung độtgiữa tên người dùng và mật khẩu, điều này có thể cho phép thựchiện một cuộc tấn công mật khẩu lên tài khoản người dùng khác.Nhắm mục tiêu một username được liệt kê hoặc đoán và cố gắngtạo các tài khoản có username này và các mật khẩu khác nhau.Khi ứng dụng thông báo lỗi đối với một mật khẩu cụ thể, có thểmật khẩu được đặt trùng với mật khẩu của tài khoản mục tiêu

Nếu ứng dụng chấp nhận được sự va chạm username vàmật khẩu mà không có lỗi, hãy đăng nhập bằng thông tin đăngnhập gây xung đột Xác định điều gì sẽ xảy ra và liệu hành vi củaứng dụng có thể bị lợi dụng để truy cập trái phép vào tài khoảncủa người dùng khác hay không

4.9.Kiểm tra khả năng dự đoán thông tin xác thực

Nếu ứng dụng tự động tạo tên người dùng hoặc mật khẩu,lấy các giá trị liên tiếp và cố gắng xác đinh quy luật của chúng

Nếu tên người dùng được tạo theo cách có thể dự đoánđược, xác định danh sách các tên người dùng hợp lệ có thể có Sửdụng cách này làm cơ sở để đoán mật khẩu tự động và các cuộctấn công khác.

Nếu mật khẩu được tạo theo cách có thể dự đoán được, xácđịnh danh sách các mật khẩu có thể được cấp cho người dùng ứngdụng khác Kết quả của bước này có thể được kết hợp với bất kỳdanh sách tên người dùng nào để thực hiện một cuộc tấn côngđoán mật khẩu

4.10 Kiểm tra truyền thông tin xác thực không an toàn

Xem qua tất cả các chức năng xác thực liên quan đến việctruyền thông tin đăng nhập, bao gồm đăng nhập chính, đăng kýtài khoản, thay đổi mật khẩu và bất kỳ trang nào cho phép xemhoặc cập nhật thông tin hồ sơ người dùng Giám sát tất cả lưulượng đi qua theo cả hai hướng giữa máy khách và máy chủ bằngcách sử dụng proxy

Xác định trường hợp mà thông tin xác thực được truyềntheo một trong hai hướng Đặt quy tắc chặn trong proxy để gắn cờcác tin nhắn chứa các chuỗi cụ thể

Nếu thông tin đăng nhập từng được truyền trong chuỗi truyvấn URL, chúng có thể bị tiết lộ trong lịch sử trình duyệt, trên mànhình, trong nhật ký máy chủ và trong tiêu đề Referer header khi

sử dụng các liên kết của bên thứ ba

Nếu thông tin đăng nhập từng được lưu trữ trong cookie,chúng có thể dễ bị tiết lộ thông qua các cuộc tấn công XSS hoặccác cuộc tấn công quyền riêng tư cục bộ

Nếu thông tin xác thực đã từng được truyền từ máy chủ đếnmáy khách, chúng có thể bị xâm phạm thông qua bất kỳ lỗ hổng

nào trong quản lý phiên hoặc kiểm soát truy cập hoặc trong mộtcuộc tấn công XSS.

Nếu thông tin xác thực đã từng được truyền qua một kết nốikhông được mã hóa, chúng rất dễ bị chặn bắt

Nếu thông tin đăng nhập được gửi bằng HTTPS nhưng bảnthân form đăng nhập được tải bằng HTTP, ứng dụng dễ bị tấncông man-in-the-middle để lấy thông tin đăng nhập

4.11 Kiểm tra phân phối không an toàn

Nếu tài khoản được tạo qua một số kênh ngoài băng tầnhoặc ứng dụng có chức năng tự đăng ký bỏ trống tất cả thông tinđăng nhập ban đầu của người dùng, hãy thiết lập phương tiệnphân phối thông tin đăng nhập cho người dùng mới Các phươngpháp phổ biến thường là gửi tin nhắn đến e-mail hoặc địa chỉ bưuđiện

Nếu ứng dụng tạo URL kích hoạt tài khoản được phân phốingoài dải, thử đăng ký nhiều tài khoản mới liên tiếp và xác địnhquy luật trong các URL bạn nhận được Nếu một xác định đượcquy luật, hãy cố gắng đoán các URL được gửi đến người dùng gầnđây và sắp tới, đồng thời cố gắng sử dụng các URL này để chiếmquyền tài khoản của họ

Thử sử dụng lại một URL kích hoạt nhiều lần và xem liệuứng dụng có cho phép điều này hay không Nếu không, khóa tàikhoản đích trước khi sử dụng lại URL và xem liệu URL có còn hoạtđộng hay không Xác định khả năng đặt lại mật khẩu người dùngkhi thực hiện hành động này

4.12 Kiểm tra lưu trữ không an toàn

Nếu chiếm được gái trị băm của mật khẩu người dùng, cầnkiểm tra các tài khoản có cùng giá trị băm Cố gắng đăng nhậpbằng các mật khẩu phổ biến để có giá trị băm phổ biến nhất

Sử dụng rainbow table để cố gắng khôi phục mật khẩu dạngrõ

4.13 Kiểm tra logic xác thực

4.13.1 Kiểm tra lỗi logic

Đối với mỗi chức năng mà ứng dụng kiểm tra thông tin đăngnhập của người dùng, bao gồm cả chức năng đăng nhập và thayđổi mật khẩu, hãy thực hiện quy trình theo cách thông thường, sửdụng tài khoản hợp lệ Lưu ý mọi tham số request được gửi đếnứng dụng

Lặp lại quy trình nhiều lần, lần lượt sửa đổi từng tham sốtheo nhiều cách khác nhau để can thiệp vào logic của ứng dụng.Đối với mỗi thông số, hãy bao gồm các thay đổi sau:

- Gửi chuỗi trống

- Xóa cặp name/value

- Gửi giá trị rất dài và rất ngắn

- Gửi chuỗi thay vì số và ngược lại

- Cùng một tham số được đặt tên nhiều lần, với các giá trịgiống và khác nhau

Kiểm tra phản hồi của ứng dụng đối với các yêu cầu trước

đó Nếu xảy ra sự bất thường nào, đưa về các trường hợp thửnghiệm tiếp theo Nếu một sửa đổi gây ra thay đổi trong hành vi,

cố gắng kết hợp điều này với các thay đổi khác để đẩy logic củaứng dụng đến giới hạn của nó