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

Lộ tập tin sao lưu mã nguồn, một lỗ hổng nguy hiểm.


Thời gian gần đây khi pentest khá nhiều website mà tôi gặp được một phương thức duy nhất đó là scan các tập tin nhạy cảm, những tập tin sao lưu và luôn cả những công cụ sao lưu dữ liệu phổ biến thì tôi nhận thấy rằng tình trạng mắc lỗi bảo mật cơ bản này diễn ra khá phổ biến, có khoảng 45% những site mà tôi lên danh sách để thử tool tồn tại các điểm yếu dạng này.

Bình thường các admin, kỹ thuật viên thường không để ý đến những tập tin đã sao lưu toàn bộ mã nguồn cũng như CSDL và thông tin quan trọng của hệ thống đang chạy vì có thể do sơ xuất hoặc họ không nghĩ rằng những file sao lưu đó không ảnh hưởng gì hoặc đơn giản là họ suy nghĩ trang web của họ có ai thèm dòm ngó,....

Nhưng đối với một hacker thì đây lại là một nguồn thông tin vô cùng quý giá và sẽ giúp họ giảm thiểu được rất rât nhiều công sức mới có thể có được những thông tin quan trọng như thế, và đương nhiên họ sẽ sử dụng triệt để những thông tin này để leo lên nắm quyền cao nhất mà họ có thể tận dụng và rồi tất nhiên người tổn hại chính là những victim bất cẩn đó.

Tôi sẽ phân tích những điểm yếu khi các bạn để lộ một trong những thông tin quan trọng dưới đây và mức độ ảnh hưởng khi kết hợp lại với nhau ra sao.

1. Lộ toàn bộ mã nguồn khi backup source và không xóa sau khi đã tải về máy để lưu trữ.
Ở tình huống này thì những thông tin mà các bạn bị lộ là toàn bộ và chẳng còn gì để mất nữa cả :)

- Với thông tin này thì tôi sẽ xem xét đến các thông tin quan trọng trong các tập tin lưu cấu hình kết nối đến CSDL của các bạn.Sau đó tôi sẽ dùng những thông tin đó để thử kết nối đến CSDL các bạn đang sử dụng qua những công cụ có sẵn vd: phpMyAdmin trên server nếu các bạn có cài đặt nó và cho phép truy cập, hoặc các bạn open port cũng như cho phép connect vào CSDL từ bên ngoài.Đến đây thì tôi hoàn toàn có thể chiếm quyền quản trị của bất kỳ người admin nào, hoặc bất kỳ thành viên nào đang tồn tại trên hệ thống của các bạn, chưa kể nếu các bạn gán đầy đủ quyền cho user quản trị CSDL đang sài, hoặc sử dụng user có quyền cao nhất là root thì khả năng chiếm được server các bạn sẽ tăng lên trên 90%.

- Ngoài ra tôi cũng sẽ tận dụng những thông tin như username, password các bạn tạo cho việc connect vào CSDL đó để thử kết nối vào một số dịch vụ quan trọng khác như SSH, FTP, Panel, Email,...Nếu may mắn mỉm cười vì các bạn sài chung mật khẩu cho các dịch vụ đó thì các bạn lại gặp nguy hiểm nhanh hơn.

- Cũng có thể trong mã nguồn sẽ kèm theo luôn cả bản sao lưu của Database trang web các bạn, và đây lại là một nguồn thông tin quý giá cho tôi khai thác, trong tình huống này tôi sẽ select ra những thông tin của người quản trị và tiến hành giải mã những mật khẩu đã được mã hóa để đăng nhập vào quyền quản trị rồi leo cao hơn để vào server các bạn.

2. Lộ toàn bộ mã nguồn khi backup source nhưng không có thông tin nào tận dụng được như ở mục số 1.

Với tình huống này thì có thể các bạn không sao lưu CSDL của các bạn, hay thông tin trong các tập tin cấu hình không sử dụng được để kết nối từ ngoài vào thì xem như các bạn có chút may mắn rồi, tuy nhiên mọi việc vẫn chưa dừng lại đây vì khi đã có được mã nguồn của các bạn tôi sẽ tiếp tục đào sâu hơn và tìm kiếm những lỗ hổng trong mã nguồn trang web của các bạn rồi tận dụng nó để tiếp tục tấn công leo cao hơn.
Ngoài ra nếu các bạn sài chung với vài trang web khác trên cùng một server thì tôi cũng có thể tận dụng thông tin kết nối CSDL đó sau khi đã khai thác vào được một trang nằm cùng server và lúc này thì có lẽ tôi không còn tốn công để local qua host các bạn mà chỉ việc kết nối thẳng đến CSDL của các bạn bởi lúc này tôi đã có quyền quản lý trên hệ thống (local) của các bạn rồi.

3. Kết luận và giải pháp.
Tóm lại như các bạn đã đọc ở mục 1 & 2 thì tôi đã gợi ý ra những hướng tấn công lợi dụng vào một điểm yếu duy nhất của các bạn là để lại tập tin backup mã nguồn và tôi phát hiện thấy, và kết quả thì các bạn cũng có thể thấy rõ rồi.Cách khắc phục thì cũng khá rõ ràng rồi đó là:

- Không sao lưu mã nguồn và để lại ngay trên server của mình với tên tập tin quá dễ đoán vd: tendomain.zip, public_html.zip, html.zip,...
- Không sử dụng chung mật khẩu quản trị CSDL cho nhiều dịch vụ khác vd: SSH, FTP, Admin, Email,...
- Hạn chế sử dụng các công cụ hỗ trợ quản trị CSDL với cài đặt và sử dụng mặc định, vd: phpMyAdmin có thể đổi thành tên truy cập mà chỉ có mình bạn biết.
- Không mở quyền cho truy cập trực tiếp từ ngoài vào CSDL của các bạn vd: chỉ cho kết nối vào CSDL ở localhost.
- Thay đổi lại toàn bộ thông tin quan trọng trên hệ thống vd: username, password của toàn bộ dịch vụ, kiểm thử lại mã nguồn để tránh bị găm mã độc,...
- Gởi lời cảm ơn đến người đã thông báo lỗ hổng cho các bạn, vì biết đâu một ngày nào đó họ sẽ lại thông báo cho bạn một lỗ hổng mới của các bạn.

Concobe

Thứ Tư, 22 tháng 3, 2017

Kịch bản tấn công vào một hệ thống với lỗ hổng SQL Injection

Đây là một tình huống thực tế và cũng khá phổ biến khi kiểm thử những hệ thống lớn và nhỏ tại VN mà tôi rút ra được, hôm nay cũng chia sẻ một phần nhỏ của quá trình pentest và những hướng xử lý phù hợp khi gặp, hoặc những bạn nào đang bí ý tưởng có thể tham khảo.

1. Hệ thống có website tồn tại lỗ hổng SQLi với quyền quản trị database là user không full quyền.
2. Hệ thống có website tồn tại lỗ hổng SQLi với quyền quản trị database là root hoặc user full quyền.
3. Hướng khắc phục dựa vào những điểm yếu ở trên.


Chúng ta bắt đầu đi vào chi tiết của từng mục.

1. Hệ thống có website tồn tại lỗ hổng SQLi với quyền quản trị database là user không full quyền.
Đây là tình huống gần như là tuyệt đối khi victim tồn tại lỗ hổng SQLi rồi, vì đại đa số các trang web thường sử dụng các dịch vụ share hosting và những nhà cung cấp dịch vụ này hiển nhiên không bao giờ cấp full quyền cho các bạn cả, và lúc này chúng ta sẽ phải tận dụng tối đa những thông tin mà chúng ta thu gom được trong quá trình khai thác lỗi SQLi và trong quá trình thu gom thông tin victim để tổng hợp những thông tin chính yếu, quan trọng để xử lý.

Với trường hợp này thì theo Concobe có lẽ tùy vào mục đích của mỗi người lúc đó sẽ có nhu cầu khai thác tới đâu, vd các bạn chỉ cần select được những thông tin lưu trữ trong database thì đến đây các bạn đã hoàn toàn thành công khi tìm được lỗ hổng SQLi, nhưng với những ai pentest và những ai có nhu cầu cao hơn, muốn chiếm được càng nhiều thông tin và quyền quản trị của victim càng tốt thì sẽ phải tiếp tục sử dụng những thông tin có được.

Mình thường tổng hợp các thông tin và dùng các công cụ để tạo ra một bộ từ điển tạm gọi là sát nhất với những thông tin của victim mà mình có được, sau đó mình sẽ dùng các công cụ để brute-force những mật khẩu của victim dựa vào bộ wordlist mới generate đó.Nếu may mắn thì các bạn có thể có được mật khẩu và đăng nhập vào khu vực quản trị của admin để bắt đầu upload lên server victim cái mà các bạn muốn upload (các bạn hiểu ý tôi rồi chứ :v ).

Còn lỡ như hôm đó các bạn mới ăn cơm hay bún,...với mực thì có lẽ các bạn nên để qua hôm sau hãy tiến hành brute-force vì theo kinh nghiệm của tôi thì nó đen thật đấy =]].Nói chơi cho vui thôi chứ không ra thì chịu chứ biết làm sao giờ?
Nói chứ đến đây cũng không hẳn là tịt hoàn toàn đâu, các bạn cũng nên ngó kỹ qua mã nguồn và cách hoạt động cũng như thông tin trong các table của database đó, biết đâu lại có cách để reset password và mình select ra rồi may mắn mỉm cười thì sao.Nhớ nhé, đừng từ bỏ, chừng nào khó quá thì cho qua thôi.


2. Hệ thống có website tồn tại lỗ hổng SQLi với quyền quản trị database là root hoặc user full quyền.

a. Dùng trình duyệt và câu truy vấn SQLi để ghi file vào hệ thống.
Cũng như trên nhưng ở tình huống này chúng ta có một thông tin giúp quá trình pentest thuận lợi hơn để leo cao hơn bởi user quản lý Database nếu được gán (Grant) full quyền sẽ tương đương với user root của hệ quản trị csdl đó :D và có thêm hai quyền cho phép chúng ta load_file và into outfile.

Với Load_file chúng ta có thể tận dụng thông qua SQLi để load lên nội dung những file tồn tại trên hệ thống đó nếu những file đó không được cấu hình và phân quyền cẩn thận, mà đa phần theo mình thấy là load được, nhất là các file lưu cấu hình CSDL website, lưu cấu hình hệ thống để nắm rõ hệ thống đang sử dụng công nghệ nào và gồm những gì để chúng ta tiến hành ghi file vào hệ thống thông qua into outfile.

Với Into outfile thì sau khi chúng ta có thông tin từ quá trình load_file như đường dẫn các thư mục của website victim, thông tin user và mật khẩu quản trị csdl,... chúng ta dùng chính query để khai thác SQLi và tiến hành ghi file vào hệ thống, rồi chiếm full quyền.

b. Dùng trình duyệt kết hợp với công cụ quản trị CSDL để ghi file vào hệ thống.
Với cách này thì cũng hên xui là chính (có thể không tìm được thư mục cho phép ghi (chmod 777) file thì sao) nhưng mình vẫn nêu ra để các bạn có thêm hướng xử lý nếu gặp phải, sẽ giúp quá trình thực hiện nhanh hơn và linh hoạt hơn so với query trên trình duyệt để ghi file.

Nếu vô tình victim có sử dụng công cụ quản lý CSDL như phpMyAdmin thì các bạn dùng nó kết hợp với thông tin đã load được từ các file config gồm username password quản lý CSDL ở bước 1 để đăng nhập và thực thi các câu truy vấn cho dẽ dàng hơn.Ngoài ra các bạn cũng có thể dùng phpMyAdmin để tiến hành update CSDL để chiếm quyền của user quản trị dễ dàng hơn rồi vào khu vực quản trị website để upload cái cần upload :(.

Nếu vẫn không tồn tại phpMyAdmin thì các bạn cũng nên thử thêm các công cụ hỗ trợ remote connect từ ngoài vào CSDL như Navicat,... để thử vận may, vì đa phần hiện nay mặc định khi cài đặt các trình quản lý CSDL đều không cho phép connect từ ngoài vào vì lý do an toàn, nhưng dù gì cũng cùng đường rồi, thử đi biết đâu lúc cài đặt lão admin lười biếng chọn next, next, yes, yes hết thì sao :D

Tóm lại phần 1 & 2 đơn giản gồm có:
- Lỗi SQL injection.
- Không có full quyền, brute-force và tìm kiếm vận may.
- Có full quyền và dùng load_file và into outfile để upload hàng họ lên.
- Tận dụng những công cụ và thông tin có sẵn để tạo thuận tiện trong quá trình pentest.


3. Hướng khắc phục dựa vào những điểm yếu ở trên.
- Kiểm thử, giám sát và quản lý hệ thống liên tục để tìm kiếm lỗ hổng và fix theo hướng chủ động.
- Cấu hình và phân quyền chặt chẽ nhưng file cấu hình của hệ thống như file config chứa thông tin CSDL website, file cấu hình web, host,...
- Cấu hình và phân quyền chặt chẽ nhưng thư mục của hệ thống đặc biệt không phân quyền 777 cho thư mục để tránh bị ghi file vào.
- Không cho phép kết nối vào CSDL từ bên ngoài, không sử dụng mặc định các công cụ quản lý dữ liệu như phpMyAdmin.
- Ngày ngày thắp nhang khấn vái và làm việc thiện để không bị ai dòm ngó, hoặc có bị dòm ngó cũng được họ thông báo fix lỗi chứ không phá hoại, nhớ cảm ơn và ủng hộ những người đó nếu có điều kiện.

Concobe một chiều rảnh rỗi.

Cyberpanel và những lỗ hổng bảo mật đã fix.

Tầm đầu tháng 1/2019 mình thấy đi group nào chuyên về thiết kế website, bán hosting,...Của facebook cũng có những comment khuyên nhau sử dụn...