Hôm nay dạo qua facebook thì thấy một challenge từ vòng loại SVATTT được đăng tải từ chính tác giả:
yeuchimse
Tranh thủ thời gian rảnh rỗi lúc còn ở VN, thấy bài này cũng hay hay nên cũng muốn writeup một tí.
Khác với tất cả 5 năm trước đây, 3 năm là thí sinh, 2 năm là BTC… Năm nay tâm thế là một bên không liên quan bất kì hoạt động gì về SVATTT, cũng là một dịp được quan sát và refresh cuộc chơi.
Edit: Sau khi trao đổi với người ra đề thì có một cách dễ hơn để leak code là dùng bug Open-redirect, như thế ta sẽ không cần phải sử dụng RPO.
http://sadbook.ctf.yeuchimse.com/login.php?utm_client=zzz&return=/report.php
Introduction
Cơ bản bài này có hai đường dẫn liên quan.
http://sadbook.ctf.yeuchimse.com/
Trang chính, show những câu nhật ký “tự kỷ” từ các user khác. Trang đăng nhập và một trang report lỗi. Với cách “bày trận” một thử thách như vậy thì người chơi có thể đoán ngay bài này thuộc thể loại Client-side attack, thường những bài như vậy, một là bạn truy xuất ra được document.cookie hoặc nội dung page nào đấy (trong đó có flag), 2 là chiếm được session của admin luôn. Lưu ý là bạn điền bất kì URL nào vào trang report, con bot của tác giả (bot ở đây giữ vai trò như một admin thật sự sẽ xem xét, và click vào đường link report của bạn) sẽ đi đến đấy, và bạn có thể thấy nó trên log server của mình. Vì vậy, nếu giả sử ta có thể đưa một link “nào đó” vào trang report, con bot chứa flag sẽ đi tới đó, và bằng cách nào đó, bạn phải lấy flag từ nó.
http://sadpen.ctf.yeuchimse.com/
Trang này cho phép bạn đăng ký tài khoản, ghi lại những câu nhật ký tình yêu … đồng thời thay đổi những thông tin cá nhân (về sau bạn sẽ hiểu tại sao tác giả cho thay đổi những thông tin này).
Sau khi bạn đăng ký và đăng nhập tài khoản của mình, kể từ lúc này bên trang
sadbook , bạn có thể sử dụng chức năng “
Đăng nhập qua Sad Pen“. Mà nó sử dụng
OAuth . Hm… nôm na là
sadpen sẽ trả về một
authorization code, và gọi
callback.php từ
sadbook, nếu code là hợp lệ, bạn sẽ được xác định bởi danh tính đấy. Vậy rất có thể admin (người mà bạn đang muốn lấy flag) đã có tài khoản trên
sadpen, và có thể cũng đang login rồi. Thế câu truyện ở đây nhiều khả năng sẽ là làm thế nào cướp được đoạn code chứng thực đó. Hình dưới là những thứ xảy ra khi bạn click vào “
Đăng nhập qua Sad Pen“.
Bước 1:
Trình duyệt truy cập trang:
http://sadpen.ctf.yeuchimse.com/oauth.php?client_id=42&type=code&redirect_uri=http%3A%2F%2Fsadbook.ctf.yeuchimse.com%2Foauth%2Fcallback.php
– Nếu bạn đã đọc sơ qua OAuth, sẽ biết khi gọi Authorization Server, chúng ta phải định danh “
redirect_uri“, để đảm bảo an toàn,
redirect_uri phải hợp lệ và pass được whitelist check với origin đã được đăng ký, ở đây là
http://sadbook.ctf.yeuchimse.com/oauth/callback.php . Vì vậy mọi URL bạn đưa vào đây đều được phải bắt đầu bởi chuỗi đấy.
Bước 2:
Về phía Authorization Server, nếu đã xác thực rằng tài khoản bên sadpen có thể dùng để auth với sadbook, sẽ gửi trả lại một Authorization Code là một chuỗi gì đấy, kèm với URL bạn chúng ta cung cấp từ trước, cho nên nó sẽ Location sang
http://sadbook.ctf.yeuchimse.com/oauth/callback.php?code=
{Authorization Code}
Code sẽ được check, nếu hợp lệ bạn sẽ được đăng nhập với danh tính tương ứng như bên sadpen.
Tips
Từ hai đường dẫn riêng biệt, sự xuất hiện của những thứ … không bình thường, kèm những chức năng cũng tương đối đặc biệt như vậy, trong một cuộc thi CTF thì chắc chắn lỗi và cách khai thác nằm trong sự liên kết của hai thứ này.
Thiệt ra cũng không hẵn là chỉ trong CTF, mà trong trường hợp thực tế, nếu những ứng dụng có những “tính năng” phức tạp, đi trái với thông thường, hoặc những trường hợp họ rất ít có cơ hội code tới thì khả năng có lỗi
sẽ tăng lên cao rất nhiều đối với những tính năng thông thường. Giống như bạn chơi giỏi LOL, dù rằng hai game cách chơi tương đối giống nhau nhưng không có điều gì đảm bảo rằng tại lần đầu tiên bạn sẽ chơi giỏi DotA, và ngược lại.
The Vulnerabilities
Bug thứ nhất nằm ở phần đường dẫn “
redirect_uri” trong khi đăng nhập bằng OAuth. Ta không thể sửa phần đầu vì đã được check rằng phải bắt đầu bởi
http://sadbook.ctf.yeuchimse.com/oauth/callback.php, nhưng ta có thể tùy ý với phần đuôi của nó.
Vậy chuyện gì sẽ xảy ra nếu ta đăng nhập bằng URL
http://sadpen.ctf.yeuchimse.com/oau.../sadbook.ctf.yeuchimse.com/oauth/callback.php/../../../index.php
Hợp lệ và ta bị dẫn sang
http://sadbook.ctf.yeuchimse.com/in...0.ezrv2uDurqJJDpJtqlz3Yx73vz_pGyBLVC9Z1apy1XA
Với “../../../” ta có thể quay ngược lại thư mục đường dẫn trước và kết thúc tại index.php, vì vậy mà code đang được truyền vào params của file “index.php” .
Hm để đó… chúng ta vẫn còn thiếu một mắt xích, một mảnh ghép nào đó để hoàn thành.
Tiếp tục tìm kiếm, mình phát hiện thêm một lỗi, đó là
RPO (Relative Path Overwrite), bạn có thể đọc chi tiết về phương thức tấn công này tại
http://www.thespanner.co.uk/2014/03/21/rpo/
Ngoài ra vào cuộc thi SVATTT 2015, mình cũng đã một lần ra một đề bài liên quan trực tiếp đến phương thức này, bạn có thể đọc writeup của nó tại đây:
https://tsublogs.wordpress.com/2015/11/08/svattt-2015-csecretboxes/
Mình nghĩ hai bài trên đã nói quá rõ ràng RPO là gì, mình sẽ không giải thích lại.
Với đường dẫn là
http://sadbook.ctf.yeuchimse.com/index.php/ . Ta có thể thấy các file css đã bị relative path làm nó trỏ lại về file index.php… mà trong đấy chứa những câu nhật ký ướt át do chính những user post lên.
Vậy sẽ ra sao nếu nhờ RPO ta có thể leak, và “chôm” được đoạn code chứng thực của admin ?! Thông qua http referer, tới đây làm mình nhớ tới một bài blog nói về một chain, gồm những bug cực kì đơn giản và low risk, để có thể cướp hoàn toàn một session của user. Bạn có thể đọc tại đây:
http://homakov.blogspot.com/2014/02/how-i-hacked-github-again.html (Đọc và hiểu cũng giúp ích cho đoạn bên dưới).
Tưởng tượng bạn truy cập vào “
https://l4w.io/” , và trong website ấy có một link ảnh đi tới server của bạn, thì có phải mỗi lần có người truy cập vào blog mình, bạn sẽ cũng nhận một http request bên phía server bạn, và referer của nó là “
https://l4w.io/” đúng không ?
The Chain
Ngẫm nghĩ về các bước, và mình đã hoàn thành một chain với các bước sau:
Tạo một user, cố gắng spam những câu nhật ký nhiều nhất, để tỉ lệ %, admin có thể “thấy” câu nhật ký của mình là cao nhất.
Sau đó sửa thông tin cá nhân lại thành payload RPO của mình, ở đây mình sử dụng câu như dưới. Vì nếu ta sử dụng
{}*{background: url(…)} thì Referer của nó sẽ là những file css chứ không phải URL “
index.php/?code=…” như chúng ta muốn, vì vậy chúng ta phải sử dụng “import…”
Tiếp theo liên tục report trên trang sadbook bằng đường link
http://sadpen.ctf.yeuchimse.com/oau.../sadbook.ctf.yeuchimse.com/oauth/callback.php/../../index.php/
Nếu con bot thấy được nội dung của mình post lên, kèm theo RPO payload là địa chỉ URL homepage mà nó sẽ xuất hiện trên trang chủ index.php, con bot sẽ tiếp tục truy cập các file css, nhưng đã bị ta đè relative path => con bot load file index.php như là một file css => chạy câu “
import …” đến URL là server của chúng ta, và
HTTP Referer sẽ là “
index.php/?code=….” kèm đoạn code chứng thực. Cùng với đoạn code này, ta có thể truy cập
http://sadbook.ctf.yeuchimse.com/oauth/callback.php?code=
{Authorization Code}
để đăng nhập vào session của admin. Sau khi có flag, bạn có thể ngay lập tức sửa lại URL homepage của mình (nơi chứa payload RPO) để xóa bỏ dấu vết, tránh làm cho các đội khác nhìn thấy,
Bingo!
Ướt át quá đọc mà mình nổi cả da gà.
