Thứ Sáu, 31 tháng 3, 2017

[PHÂN TÍCH] Vntrip đã lộ thông tin khách hàng như thế nào?


     VnTrip đã lộ thông tin khách hàng như thế nào?
     Đã từng thông báo cho tổng đài bên VnTrip nhưng không nhận được hồi âm. Nhưng VnTrip cũng đã tự khắc phục lại được lỗi trên Server của họ nên cũng rất đáng mừng.
     Bài viết này mang tính chất phân tích để cho các DEV quan tâm hơn về vấn đề bảo mật của Mobile App sau nhiều vụ lộ lọt thông tin trước đây.
     Tiếp tục RE Mobile App của VnTrip download trên apkpure, app này được build cách đây khá lâu từ nửa năm trước.
     Sau khi RE Mobile App của VnTrip (hiện nay vẫn dùng phiên bản App đó) ta sẽ thu được 2 services: 1 là services của User, 1 là service của Admin.    
     Khi các DEV lập trình thường thường sẽ có rất nhiều phiên bản Services khác nhau như: Test, Admin, User... và chúng thường sử dụng một mẫu API chung, có thể Services chính của các DEV sẽ an toàn và được bảo mật nhưng những Services phụ, Services Test,... không được quan tâm đúng mực và những Services như vậy chính là những lỗ hổng giúp các Attacker (Pentester/Hacker) khai thác được những thông tin cần thiết.
     Ví dụ như khi ta sử dụng Django Framework (cái này mình dùng làm đồ án nên hay lấy ra) thì một số chức năng bảo mật thường được disable để cho các DEV dễ dàng hơn trong việc lập trình, nhưng từ những sơ hở đó có thể tạo ra những hệ qủa với Services chính. Services chính mặc dù đã enable những chức năng bảo mật nhưng lại dùng chung API với Services Test nên như vậy các Attacker dễ dàng xâm nhập hệ thống qua các API từ đó truy xuất được những dữ liệu.
     Vì vậy khuyến cáo các DEV nên xử lý toàn bộ các services với các chức năng bảo mật như ở Services chính hoặc có thể xóa bỏ Services Test nếu không cần thiết.
     Trong trường hợp của server T thì từ services Admin ta có thể tìm ra điểm tương đồng ở services User từ đó khai thác và lấy được toàn bộ thông tin Orders.
     Còn việc tìm ra những API, những Directory thì các DEV cũng nên cẩn thận fix từng lỗi một trong những dòng code của mình và pentest thật kỹ lưỡng trước khi đưa ra thị trường. Nên sử dụng các token, sessionession hợp lý trong từng sản phẩm của mình.
     Bài tiếp theo là một Tools Attack nho nhỏ viết bằng Python rất mong được sự ủng hộ, gíup đỡ của mọi người.

Thứ Sáu, 10 tháng 3, 2017

[PHÂN TÍCH] 12bay đã lộ thông tin khách hàng như thế nào?

     Như đã nói ở những phần trước sau đây mình xin viết bài về 12bay.
     Dạo này thấy mấy site về hàng không bị tấn công nhiều qúa, mình mạn phép làm thêm 1 bài về 12bay đã lộ thông tin khách hàng như thế nào?
     12bay là một trang đặt vé cũng khá là nổi tiếng tại Việt Nam. Với lượng đặt vé hàng ngày lên đến hàng trăm đơn. Cùng với cái sở thích pentest thì mình lại nghịch ngợm xem sao. (Bạn Dev cũng nhờ mình PenTest hôm rảnh rảnh nói chuyện nhưng quên chưa lấy số).
     Hehe, tên miền của trang này cũng khá hay, lượng truy cập cũng khá đông, tấn công thôi.
     Vì những MobileApp thường bảo mật rất kém như ở bài trước nên mình lại tiếp tục tìm thông qua MobileApp, đầu tiên tải file APK của App trên APKpure về.
     App này cũng khá là được quan tâm, rất hay cập nhật những tính năng mới nhưng mà vẫn chả quan tâm gì đến bảo mật.
     Tải về thôi được 1 file .apk.
     Tiếp tục unzip ta thu được source bên trong file apk.
     Sau một thời gian Reverse engineering thì mình có thu được một đoạn api có dạng:
     "http://server12bay.vn/Api/.../info.php?id=" Web App này hôm mình nghịch thì không có được mã hóa nhưng sau đó vài hôm đã được mã hóa ngay chắc thấy lượng truy cập nhiều qúa. Web App này cho chúng ta biết được những thông tin:
     Tên, pnrcode, giờ bay, tiền bay...
     Không nản chí tiếp tục với đoạn api thứ 2 có dạng:
     Tiếp tục với kỹ thuật Buffer Overflows ta có API tiếp theo.
     "http://server12bay.vn/Api/.../success.php?id="Web App này đưa thông tin dưới dạng JSON. Hay rồi đấy, rất ngắn gọn chả có nội dung gì cả nhưng... cái hay lại ở chỗ đó.
     Mình tiếp tục sử dụng kỹ thuật SQLinjection với đoạn api đó thì kết qủa thu được lại rất bất ngờ.





     Tèn ten toàn bộ dữ liệu khách hàng đặt vé đã được thu thập.
     Thời gian:
     Ngày 10/03/2017
     8:38 AM - Thông báo cho bên tổng đài, bên tổng đài nhắn tin lại bảo tự liên hệ với bên kỹ thuật. Feeling sad.
     8:40 AM - Thông báo qua facebook cho bên kỹ thuật.
     8:00 PM - Gọi và được bạn Kỹ thuật gọi lại cả 2 bên đã hợp tác và vá lỗ hổng này cũng như những lỗ hổng khác.
     Ngày 11/11/2019
     Thi thoảng nhớ lại tự nhiên thấy bồi hồi và lại xin bạn kỹ thuật cái code giảm giá. =))

     Công cụ sử dụng: jd-gui, sqlmap, dirb, addon firefox sqlite...