Phương pháp Pentest tổng quan phần 1
Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (475.65 KB, 50 trang )
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. Tuy
rằng phương pháp này khơng giúp tìm ra tất cả các lỗ hổng ứng
dụng nhất định nhưng sẽ đảm bảo được rằng kiểm thử tất cả khu
vự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ương
phá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ác
bướ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ác
nhiệm vụ được tổ chức và sắp xếp phụ thuộc lẫn nhau. Trong
phươ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ộc
tấn cơng tập trung hơn. Ví dụ: một lỗi kiểm soát truy cập
cho phép liệt kê danh sách người dùng để thực hiện các
cuộ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ểm
tra ở chức năng khác. Ví dụ: lỗ hổng lộ mã nguồn chương
trình cho phép đánh giá chức năng chính của ứng dụng
theo 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ện
một lỗ hổng nhất định ở chức năng khác để chuyển
hướ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òng
thủ 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ận
Quy trình trong phương pháp luận này giúp cho cơng việc
kiểm thử tránh khỏi các sơ suất khơng đáng có, nhưng không bắt
buộc tuân thủ cứng nhắc. Các nhiệm vụ được mô tả trong phương
pháp luận này phần lớn là tiêu chuẩn và chính thống, các cuộc tấn
cơ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ần
tuân thủ một số lưu ý chung, có thể áp dụng cho tất cả các khu
vự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 URL
encode 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 truy
vấn URL và nội dung message. Để chèn một ký tự & cần
encode thành %26.
- = được dùng để phân tách tên và giá trị tham số trong
chuỗi truy vấn và nội dung message. Để chèn một ký tự
= cần encode thành %3d.
- ? được dùng để đánh dấu bắt đầu chuỗi truy vấn URL. Để
chèn ký tự ? cần encode thành %3f.
- Khoảng trắng (space) được dùng để đánh dấu kết thúc
URL trong request và cho biết phần cuối của giá trị
cookie trong Cookie Header. Để chèn khoảng trắng cần
encode thành %20 hoặc +.
- + là encode của khoảng trắng nên để chèn ký tự + cần
encode thành %2b.
- ; được dùng để tách các cookie riêng lẻ trong Cookie
header. Để 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ủ.
Để chèn ký tự # cần encode thành %23
- % được dùng làm tiền tố của các giá trị mã URL. Để chèn
ký tự % cần encode thành %25
- Mọi ký tự null byte và enter phải được encode URL thành
%00 và %0a tương ứng.
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ặn
bắt các request.
Trong nhiều trường hợp kiểm thử, người kiểm thử cần thực
hiệ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ích
hoạt hay chưa. Trong mọi trường hợp khi đầu vào cụ thể dẫn đến
hành vi bất thường, cần kiểm tra lại xem việc gửi request lành
tính có gây ra kết quả tương tự hay khơng. Nếu có, khơng thể kết
luậ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 request
trước đó gây ảnh hưởng đến việc phản hồi các request khác. Đôi
khi, muốn khai thác một lỗ hổng dự kiến và xác định nguyên nhân
của các hành vi bất thường cần phải loại bỏ ảnh hưởng của các
trạ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ường
bằng các request lành tính sau đó khai thác thác lại. Thơng
thường, có thể lặp lại bước refresh này bằng cách điều chỉnh các
phần của cookie request container và thông tin bộ nhớ đệm.
ngồ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 đó HTTP
request 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ấu
hình ảnh hưởng đến kết quả khai thác. Ngồi ra, một số cuộc tấn
cơng thành cơng dẫn đến thay đổi trạng thái máy chủ chẳng hạn
như 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 tra
kết quả của từng request cho đến khi nhận được kết quả từ máy
chủ liên quan.
Khi triển khai kiểm thử ứng dụng web, người kiểm thử phải
xá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 sao
lư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ích
nộ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 được
cho phép và chặn. nhiều ứng dụng có thể xử lý các cấu hình trình
duyệ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ữu
cung 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ị proxy
chặn lại để hiểu dữ liệu nào đang được trao đổi và cách ứng dụng
phía client sử dụng để kiểm số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ăng
chưa được kiểm tra (ví dụ: trong Burp Spider, kiểm tra Linked
From details). Truy cập từng chức năng bằng trình duyệt để spider
phân tích cú pháp phản hồi của máy chủ để xác định các thành
phần khác. Lặp lại bước này cho đến khi không xuất hiện thành
phần chức năng nào khác.
Khi đã duyệt web theo cách thủ công và thụ động, người
kiểm thử có thể chủ động thu thập thông tin ứng dụng bằng các
công cụ quét với từng URL đã biết. bước này có thể làm xuất hiện
cá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ểm
tra.
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ư Wayback
Machine) để 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 ứng
dụng hiện tại thì vẫn có thể xem trong cache của cơng cụ tìm
kiế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ện
trong nội dung ứng dụng, chẳng hạn như thông tin liên hệ. bao
gồm cả thông tin khơng hiển thị như HTML comment. Ngồ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ỳ chi
tiế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ác
mục không tồn tại. thực hiện một số request thủ công đối với các
tài nguyên hợp lệ và không hợp lệ, so sánh các response của máy
chủ để 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ức
năng ẩn của máy chủ như HTML comment hay các thành phần
form 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ác
chứ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
headers
như
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ăng
riê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ình
thơ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ăng
thay vì URL. Kiểm tra các chức năng, luồng logic và sự phụ thuôc
giữ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ất
hiện trong các chức năng chính như đăng nhập, tìm kiếm, tải lên
hoặ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). Đối
với mỗi cặp tên tham số/giá trị. Gửi từng cặp cho mỗi hàm mục
tiê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 trong
Burp 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 định
các trường hợp mà thông số thêm vào có ảnh hưởng đến q trình
xử lý của ứng dụng.
2.
Phân tích ứng dụng
Hình 2.2 phân tích ứng dụng
2.1. Xác định hàm
Xác định các chức năng cốt lõi của ứng dụng và hoạt động
của mỗi chức năng khi chúng hoạt động bình thườ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ạn
chuyển hướng, liên kết ngồi, thơng báo lỗi và các chức năng
quả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ụng
khơng.
Xác ddnhj các kênh ngồi băng tần mà thơng qua đó người
dùng có thể kiểm sốt dữ liệu của bên thứ 3 khác được đưa vào
quá 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áy
khách, chẳng hạn form, scripts, cookie, Java Applets, ActiveX
controls, đối tượng Flash.
Xác định cơng nghệ đang sử dụng phía máy chủ, gồm ngôn
ngữ kịch bản, nền tảng ứng dụng, cách tương tác với các thành
phầ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ác
responsese, đồng thời kiểm tra các mã nhận dạng phần mềm
khá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 định
các phần mở rộng tệp, thư mục hoặc URL có thể cung cấp manh
mối về cơng nghệ đang sử dụng trên máy chủ. Kiểm tra session
token và cookie. Sử dụng Google để tìm kiếm các cơng nghệ liên
quan.
Xác định các tập lệnh chứa các chuỗi tham số truy vấn
thuộ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 được
lê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ức
nă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ăng
xuấ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 Path
traversal, 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ụ chi
tiế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 sốt phía máy khách
Hình 3.3 kiểm tra kiểm số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ợp
trên trong logic ứng dụng thông qua ngữ cảnh mà nó xuất hiện
cũ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 đến
vai 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 sốt
bả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ếu
trường bị làm rối hay encode, hãy giải mã thuật tốn trộn/encode
đó để thay thế dữ liệu cần thiết. ngay cả khi dữ liệu được mã hóa
an tồ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ết
thê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 hay
khơng. Tuy nhiên, ViewState có thể dùng khác nhau trên các trang
khá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ạy
cảm hay khơng.
- Sửa đổi một trong số các giá trị tham số rồi mã hóa lại
ViewState. 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ào
quá 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 số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ới
hạn độ dài, kiểm tra JavaScript xác thực thông tin đầu vào trước
khi chúng được gửi tới server. Các kiểm sốt này có thể bypass để
request tùy ý đến server. Ví dụ:
onsubmit=”return
Validate(this)”>
<input maxlength=”3” name=”quantity”>
…
Lần lượt kiểm tra các trường đầu vào bằng cách sử dụng
các dữ liệu đầu vào không hợp lệ để xác minh xem chúng có được
copy đến server hay khơng.
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 đang
thực hiện. xác định liệu ứng dụng có đang dựa vào kiểm sốt phía
client để 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ác
củ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. Ngồi ra, có thể sử
dụng proxy tự động để tự đơng vơ hiệu hóa các trường, chẳng hạn
HTML 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 Dser
Burp plugin dành cho java.
o Xác định các chức năng nhạy cảm, sử dụng các
công cụ chặn để phát lại request hoặc sửa đổi phản
hồ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 được
các thẻ applet trong mã nguồn HTML ví dụ:
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 hay
khơng. Nếu dữ liệu bị encode/encrypt, có thể phải
dịch ngược để lấy mã nguồn.
o Tải mã bytecode của applet từ trình duyệt. tên file
bytecode được chỉ định trong thuộc tính của thẻ
applet. File sẽ được lưu trong thư mục được chỉ định
trong 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ộng
trì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ằng
WinRar hoặc WinZip trước.
o Kiểm tra lại mã nguồn có liên quan để hiểu q 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ác
xá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ằng
cách sử dụng các công cụ biên dịch do nhà cung cấp
cung 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 tồn bộ ứng dụng, sửa đổi và đóng gói
lại mà khơng gặp nhiều lỗi. đối với các ứng dụng
nà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, Silverlight
Spy 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à ứng
dụng dùng để quản lý logic nghiệp vụ và đặt
breakpoint 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ặc
các thẻ object HTML. Ví dụ:
codebase=”https://wahh
app.com/scripts/input.cab”
id=”TheAxControl”>
</OBJECT>
o Thơng thường, có thể hủy bỏ các xác thực đầu vào
được thực hiện trong ActiveX control bằng cách gắn
các tham số gỡ lỗi và sửa đổi trực tiêp dữ liệu đang
được xử lý hoặc thay đổi đường dẫn thực thi của
chương trình. Xem chương 5 để biết thêm chi tiết.
o Có thể đốn mục đích của các phương thức ActiveX
dự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ương
thức. kiểm tra các trường có khả năng dự đố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ặc
xá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ạo
cá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ỗi
như tràn bộ đệm.
4.
Kiểm tra xác thực
Hình 4.4 Kiểm tra cơ chế xác thực
4.1. Hiểu cơ chế
Xác định các công nghệ xác thực được sử dụng (ví dụ: form,
chứng chỉ, đa yếu tố).
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ười
dùng.
Sử dụng chức năng đăng ký hoặc thay đổi mật khẩu, đặt
nhiều loại mật khẩu yếu khác nhau để xác định các quy tắc được
thực thi trong thực tế. thử với mật khẩu ngắn, chỉ có chữ/số, các
mậ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ực
hiên đăng nhập bằng các biến thể khác nhau của mật khẩu này
như 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 q trình xác thực nào đang được
thự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ấn
cơ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 tn 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ức
nă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 request
gồ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 server
phản hồi. các thay đổi có thể rất nhỏ (ví dụ: cùng thơng báo lỗi
như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 so
sá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ười
dùng tự động.
Kiểm tra nguồn rị rỉ thơng tin cho phép liệt kê tên người
dù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. hai
trường hợp chính thường là đăng nhập và thay mật khẩu. chức
nă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ưng
thô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ông
thành công, nếu ứng dụng khơng thơng báo khóa tài khoản, đăng
nhậ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ười
dù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ản
khi quên thông tin đăng nhập. thường là chức năng Quên mật
khẩu.
Xác định hoạt động của chức năng khôi phục tài khoản
bằng cách thực hiện tồn bộ quy trình khơi phục bằng tài khoản
kiể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ủa
riêng họ trong khi đăng ký hay khơng. Nếu có, sử dụng danh sách
username đã 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ập
danh sách các gợi ý mật khẩu và xác định các mật khẩu dễ đốn.
Thực hiện tương tự đối với các trường hợp khơi phục tài
khoản đối với tài khoản đã thực hiện tại chức năng đăng nhập
chí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 để
hồn tất q trình khơi phục, tìm điểm yếu cho phép bạn kiểm
sốt tài khoản của người dùng khác. Xác định xem có thể kiểm
số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-mail
hợ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ười
dùng có thể dự đốn.
Ngay cả khi dữ liệu lưu trữ được encode/encrypt, kiểm tra
các thông tin xác thực khác để xác định cơ chế và tìm cách
decode/decrypt. Áp dụng phương pháp được mô tả trong chương
5.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ách
phù hợp nhằm cố gắng giả dạng thành những người dùng khác
củ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ột
ngườ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ông
cầ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ười
dù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ột
mậ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ười
dùng điền username mong muốn, thử đăng ký hai lần cùng một
username 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 đã đăng
ký.
Nếu ứng dụng đăng ký cả hai tài khoản, xác định hành vi
củ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ới
mật khẩu của tài khoản kia. Ngoài ra, xác định hành vi ứng dụng
khi đăng ký hai tài khoản có tên người dùng và mật khẩu giống
hệt nhau.
Nếu ứng dụng cảnh báo hoặc tạo ra lỗi khi xảy ra xung đột
giữa tên người dùng và mật khẩu, điều này có thể cho phép thực
hiệ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ắng
tạ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 đăng
nhậ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ản
của người dùng khác hay không.
4.9. Kiểm tra khả năng dự đố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ộc
tấn công khác.
Nếu mật khẩu được tạo theo cách có thể dự đốn được, xác
định danh sách các mật khẩu có thể được cấp cho người dùng ứng
dụ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
đốn mật khẩu.
4.10.Kiểm tra truyền thơng tin xác thực khơng an tồn
Xem qua tất cả các chức năng xác thực liên quan đến việc
truyề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 xem
hoặc cập nhật thông tin hồ sơ người dùng. Giám sát tất cả lưu
lượng đi qua theo cả hai hướng giữa máy khách và máy chủ bằng
cách sử dụng proxy.
Xác định trường hợp mà thông tin xác thực được truyền
theo 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 truy
vấn URL, chúng có thể bị tiết lộ trong lịch sử trình duyệt, trên màn
hì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ặc
cá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ủ đến
má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ột
cuộ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ối
khơ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ản
thân form đăng nhập được tải bằng HTTP, ứng dụng dễ bị tấn
cô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 tồn
Nếu tài khoản được tạo qua một số kênh ngồi băng tần
hoặ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ện
phân phối thông tin đăng nhập cho người dùng mới. Các phương
phá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ối
ngồi dải, thử đăng ký nhiều tài khoản mới liên tiếp và xác định
quy luật trong các URL bạn nhận được. Nếu một xác định được
quy 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ếm
quyề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ài
khoả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ùng
khi thực hiện hành động này.
4.12.Kiểm tra lưu trữ khơng an tồn
Nếu chiếm được gái trị băm của mật khẩu người dùng, cần
kiểm tra các tài khoản có cùng giá trị băm. Cố gắng đăng nhập
bằ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ạng
rõ.
