HỌC VIỆN CÔNG NGHỆ BƯU CHÍNH VIỄN THÔNG

KHOA AN TOÀN THÔNG TIN

---------------------------------

BÀI THỰC HÀNH 2

Họ và tên : Nguyễn Thị Trang

Mã sinh viên: B20DCAT188
Nhóm lớp: 01
Giảng viên: Vũ Minh Mạnh

1
Bài 1: Unprotected admin functionality

Trong bài lab, lỗi quản trị không được bảo vệ là một vấn đề bảo mật phổ
biến. Lỗi này xảy ra khi trang quản trị của ứng dụng web không có bất kỳ biện
pháp bảo vệ nào để ngăn chặn người dùng không được phép truy cập vào nó.
Trang quản trị thường chứa các chức năng quan trọng và nhạy cảm, như
quản lý người dùng, cấu hình hệ thống, cơ sở dữ liệu, và các tác vụ quản lý khác.
Nếu không được bảo vệ một cách đúng đắn, trang quản trị có thể trở thành mục
tiêu cho các hacker hoặc kẻ tấn công, cho phép họ tiếp cận và thực hiện các hoạt
động bất hợp pháp hoặc gây hại đến hệ thống.

1.Truy cập bài lab

2.Xem robots.txt bằng cách thêm "/robots.txt" vào cuối URL của lab. Lưu ý rằng
dòng Disallow sẽ tiết lộ đường dẫn đến trang quản trị.
Việc truy cập vào trang quản trị không được bảo vệ được thực hiện bằng
cách tiết lộ đường dẫn đến trang quản trị trong tệp robots.txt. Tệp robots.txt thường
được sử dụng để hướng dẫn các công cụ tìm kiếm không truy cập vào những phần
của trang web mà quản trị viên không muốn hiển thị công khai. Tuy nhiên, trong
trường hợp này, tệp robots.txt chứa thông tin quan trọng về đường dẫn đến trang
quản trị, và điều này cho phép kẻ tấn công biết được cách truy cập vào trang quản
trị mà không cần xác thực.

2
3.Trong thanh địa chỉ URL, thay thế "/robots.txt" bằng "/administrator-panel" để
tải trang quản trị.

4.Xóa người dùng có tên "carlos" để hoàn thành lab.

Với việc truy cập vào trang quản trị, người giải bài lab có thể thực hiện các
hành động như xóa người dùng "carlos". Điều này chỉ ra rằng, do lỗi không được
bảo vệ, kẻ tấn công có thể thực hiện các hành động không được ủy quyền và có thể
gây hại đến hệ thống.

⇒ Để khắc phục lỗi này, trang quản trị cần được bảo vệ bằng cách áp dụng các
biện pháp bảo mật như xác thực mạnh mẽ, quản lý phiên làm việc, kiểm tra phân
quyền và kiểm tra và xác thực đầu vào.
3
Bài 2: User role can be modified in user profile
Trong bài lab, lỗi quan trọng nằm ở khả năng thay đổi vai trò của người
dùng thông qua hồ sơ người dùng. Lỗi này cho phép kẻ tấn công thay đổi vai trò
của chính mình và có quyền truy cập vào trang quản trị, vượt qua các giới hạn và
kiểm soát truy cập của hệ thống.

1.Đăng nhập bằng thông tin đăng nhập được cung cấp: tên đăng nhập là "wiener"
và mật khẩu là "peter".

2.Sử dụng tính năng được cung cấp để cập nhật địa chỉ email liên kết với tài khoản
của bạn.

3.Quan sát rằng phản hồi từ máy chủ chứa ID của vai trò của bạn.

4
4.Gửi yêu cầu cập nhật email qua Burp Repeater, thêm "roleid":2 vào JSON trong
phần thân yêu cầu và gửi lại yêu cầu đó. Quan sát rằng phản hồi từ máy chủ cho
thấy vai trò của bạn đã thay đổi thành 2.
Kẻ tấn công có thể tận dụng lỗ hổng này bằng cách thay đổi vai trò của
chính mình thành vai trò có quyền truy cập vào trang quản trị, từ đó thực hiện các
hoạt động không được ủy quyền như xóa người dùng khác.

5
5.Truy cập vào đường dẫn /admin và xóa người dùng "carlos" để hoàn thành bài
lab.

6
 Lỗi này có thể xảy ra khi việc kiểm tra và xác thực phía máy chủ không
được thực hiện một cách đúng đắn. Khi người dùng gửi yêu cầu cập nhật hồ sơ
người dùng và thay đổi vai trò của mình, máy chủ không kiểm tra xem người dùng
có quyền thực hiện thay đổi đó hay không. Thay vào đó, yêu cầu được chấp nhận
và vai trò của người dùng được thay đổi mà không có bất kỳ kiểm soát bổ sung
nào.

⇒Để khắc phục lỗi này, ứng dụng web cần áp dụng các biện pháp bảo mật như
kiểm tra và xác thực đúng đắn cho các yêu cầu cập nhật hồ sơ người dùng. Nó
cũng nên áp dụng quản lý phiên làm việc và kiểm tra phân quyền để đảm bảo rằng
chỉ có những người dùng có quyền truy cập vào trang quản trị mới có thể thực
hiện các thay đổi liên quan đến vai trò.

3.Username enumeration via account lock

Bài lab tập trung vào lỗ hổng về việc tìm kiếm tên người dùng thông qua việc khóa
tài khoản. Ứng dụng web sử dụng khóa tài khoản khi có quá nhiều lần đăng nhập
không hợp lệ, tuy nhiên, điều này chứa một lỗi về logic. Mục tiêu của bài lab là tìm
kiếm một tên người dùng hợp lệ, tấn công dò mật khẩu cho người dùng này, sau đó
truy cập trang thông tin tài khoản của họ.

1.Sử dụng công cụ Burp để nghiên cứu trang đăng nhập và gửi một tên người dùng
và mật khẩu không hợp lệ. Gửi yêu cầu POST /login tới Burp Intruder.

7
2.Chọn loại tấn công "Cluster bomb". Thêm một vị trí payload cho tham số tên
người dùng (username). Thêm một vị trí payload trống vào cuối phần thân yêu cầu
bằng cách nhấp vào "Add §" hai lần. Kết quả như sau:
username=§invalid-username§&password=example§§

3.Trên tab Payloads, thêm danh sách các tên người dùng vào payload set đầu tiên.
Đối với payload set thứ hai, chọn loại Null payloads và chọn tùy chọn để tạo ra 5
payloads. Điều này sẽ làm cho mỗi tên người dùng được lặp lại 5 lần. Bắt đầu tấn
công.

8
4.Trong kết quả, chú ý rằng phản hồi cho một trong các tên người dùng có độ dài
lớn hơn so với phản hồi khi sử dụng các tên người dùng khác. Xem xét kỹ hơn
phản hồi đó và chú ý rằng nó chứa một thông báo lỗi khác: "You have made too
many incorrect login attempts". Ghi chú tên người dùng này lại.

5.Tạo một cuộc tấn công mới trên yêu cầu POST /login bằng Burp Intruder, nhưng
lần này chọn loại tấn công "Sniper". Đặt tham số tên người dùng (username) là tên
người dùng bạn vừa xác định và thêm một vị trí payload cho tham số mật khẩu
(password).

9
6.Thêm danh sách các mật khẩu vào payload set và tạo một quy tắc trích xuất grep
cho thông báo lỗi. Bắt đầu tấn công.

7.Trong kết quả, nhìn vào cột "grep extract". Chú ý rằng có một vài thông báo lỗi
khác nhau, nhưng một trong số các phản hồi không chứa bất kỳ thông báo lỗi nào.
Ghi chú mật khẩu này lại.

10
8.Đợi một phút để cho phép khóa tài khoản được đặt lại. Đăng nhập bằng tên
người dùng và mật khẩu bạn đã xác định và truy cập vào trang thông tin tài khoản
người dùng để giải quyết bài lab.

11
Bài 4: Host header authentication bypass
Lỗ hổng do ứng dụng không thực hiện việc xác thực người dùng một cách
đáng tin cậy và dựa vào giá trị của tiêu đề Host để xác định quyền hạn của người
dùng.
Thông thường, xác thực người dùng được thực hiện bằng cách yêu cầu
người dùng cung cấp thông tin như tên đăng nhập và mật khẩu. Tuy nhiên, trong
trường hợp này, ứng dụng không sử dụng phương pháp này mà thay vào đó, nó
dựa vào giá trị của tiêu đề Host trong yêu cầu HTTP.

Tiêu đề Host thường được sử dụng để chỉ định tên miền hoặc địa chỉ IP của
máy chủ mà yêu cầu được gửi đến. Trong bài lab này, ứng dụng quyết định quyền
hạn của người dùng dựa trên giá trị của tiêu đề Host. Nếu giá trị này được coi là
hợp lệ, ứng dụng cho phép truy cập vào các chức năng không được phép.

1.Gửi yêu cầu GET / nhận được phản hồi 200 đến Burp Repeater. Lưu ý rằng bạn
có thể thay đổi tiêu đề Host thành một giá trị tùy ý và vẫn có thể truy cập thành
công vào trang chủ.

12
2.Duyệt đến tệp /robots.txt và quan sát rằng có một bảng điều khiển quản trị ở
/admin.

13
3.Thử duyệt đến /admin. Bạn không có quyền truy cập, nhưng lưu ý thông báo lỗi,
cho thấy bảng điều khiển có thể được truy cập bởi người dùng cục bộ.

4.Gửi yêu cầu GET /admin đến Burp Repeater.

5.Trong Burp Repeater, thay đổi tiêu đề Host thành "localhost" và gửi yêu cầu.
Quan sát rằng bạn đã thành công truy cập vào bảng điều khiển quản trị, nơi cung
cấp tùy chọn xóa các người dùng khác nhau.
Việc giả mạo giá trị tiêu đề Host thành "localhost" cho phép người dùng
vượt qua cơ chế xác thực và truy cập vào bảng điều khiển quản trị. Điều này có thể
14
dẫn đến việc thực hiện các hành động không được phép, như xóa người dùng hoặc
thay đổi cấu hình hệ thống.

6.Thay đổi dòng yêu cầu thành GET /admin/delete?username=carlos và gửi yêu
cầu để xóa người dùng "carlos" và giải quyết bài lab.

➔Để khắc phục lỗ hổng này, ứng dụng cần thực hiện việc xác thực người dùng
một cách đáng tin cậy bằng cách sử dụng phương pháp xác thực như tên đăng
nhập và mật khẩu, và không dựa vào thông tin không đáng tin cậy như giá trị tiêu
đề Host.
15
Bài 5: Remote code execution via web shell upload
Lỗ hổng trong bài lab "Remote code execution via web shell upload" liên
quan đến chức năng tải lên hình ảnh của ứng dụng. Ứng dụng không thực hiện bất
kỳ kiểm tra nào trên các tệp mà người dùng tải lên trước khi lưu chúng vào hệ
thống tệp của máy chủ. Điều này có nghĩa là người dùng có thể tải lên bất kỳ tệp
nào, bao gồm cả các tệp có mã độc.

Vấn đề xảy ra khi người dùng tải lên một tệp chứa một web shell PHP. Web
shell là một đoạn mã độc hại được nhúng vào một tệp PHP, cho phép kẻ tấn công
thực thi mã từ xa trên máy chủ. Trong trường hợp này, việc tải lên tệp web shell
PHP cho phép kẻ tấn công thực thi mã trên máy chủ ứng dụng và có quyền truy
cập vào các tệp và dữ liệu khác trên hệ thống.

Trong bài lab, chúng ta được yêu cầu tải lên một web shell và sử dụng nó để
lấy thông tin từ tệp /home/carlos/secret, thông tin này được xem là bí mật và cần
được gửi đi để hoàn thành bài lab.

Lỗ hổng này là kết quả của việc không có quá trình kiểm tra và xác thực đầy
đủ trên các tệp được tải lên từ phía người dùng. Điều này cho phép kẻ tấn công tải
lên các tệp chứa mã độc và thực thi mã đó trên máy chủ ứng dụng, mở ra cánh cửa
cho các cuộc tấn công từ xa và chiếm quyền điều khiển hệ thống.

1. Sử dụng công cụ Burp để chuyển hướng lưu lượng qua và đăng nhập vào tài
khoản của bạn. Chú ý đến tùy chọn tải lên hình đại diện (avatar).

16
2. Tải lên một hình ảnh bất kỳ, sau đó quay lại trang tài khoản của bạn. Chú ý rằng
một bản xem trước của avatar của bạn được hiển thị trên trang.

3. Trong Burp, điều hướng đến Proxy > HTTP history. Nhấp vào thanh lọc để mở
hộp thoại Thiết lập bộ lọc. Dưới Mô tả MIME, bật tùy chọn Images, sau đó áp
dụng thay đổi.

17
4. Trong lịch sử proxy, chú ý rằng hình ảnh của bạn được lấy bằng một yêu cầu
GET đến /files/avatars/<YOUR-IMAGE>. Gửi yêu cầu này đến Burp Repeater.

5. Trên hệ thống của bạn, tạo một tệp có tên là exploit.php, chứa một đoạn mã để
lấy nội dung của tệp bí mật của Carlos. Ví dụ:
<?php echo file_get_contents('/etc/passwd'); ?>

18
6. Sử dụng chức năng tải lên hình đại diện để tải lên tệp PHP độc hại của bạn.
Thông báo trong phản hồi xác nhận rằng việc tải lên này đã thành công.

7. Trong Burp Repeater, thay đổi đường dẫn của yêu cầu để trỏ đến tệp PHP của
bạn:

19
8. Gửi yêu cầu. Chú ý rằng máy chủ đã thực thi kịch bản của bạn và trả lại kết quả
(bí mật của Carlos) trong phản hồi.
<?php echo file_get_contents('/home/carlos/secret'); ?>

20
9. Gửi Submit solution để giải quyết bài lab.

21