Cách Đánh Sập Trang Web

      61

Tôi bắt đầu học về bảo mật thông tin và hack từ mùa hè năm ngoái. Sau một năm kinh qua các cuộc thi CTF, wargame, giả lập kiểm tra thâm nhập (penetration testing simulation), hiện tại tôi vẫn đang tiếp tục nâng cao kỹ năng hacking đồng thời học thêm nhiều điều mới về việc làm thế nào để khiến cho máy tính hoạt động lệch khỏi những hành vi trong dự kiến.

Bạn đang xem: Cách đánh sập trang web

Nói ngắn gọn, kinh nghiệm về bảo mật của tôi luôn bị giới hạn trong các môi trường giả lập. Và vì ngay từ ban đầu, tôi luôn tự ý thức rằng mình là một hack-er mũ trắng (whitehat), nên tôi không bao giờ “chỏ mũi” vào công việc của người khác.Cho đến hôm nay thì mọi chuyện đã khác. Sau đây là câu chuyện chi tiết về cách mà tôi đã hack vào một Server đang được dùng để lưu trữ 40 websites và những kiến thức tôi đã thu được.

Một người bạn đã nhắn tin cho tôi rằng có một lỗi về XSS đã được tìm thấy ở trang web của anh ấy, và cậu ta muốn tôi tìm hiểu sâu hơn về độ bảo mật ở hệ thống anh ta đang sử dụng. Đây là một yêu cầu quan trọng, tôi đã bảo người bạn của mình trình bày mong muốn của anh ấy bằng dạng văn bản chính thức, rằng sẽ cho phép tôi có quyền được thực hiện một cuộc kiểm tra toàn diện trên trang Web của anh ta cũng như trên Hosting đang dùng để lưu trữ trên Server. Và anh ấy đã Đồng ý.


*
*
*
*
*
*
*

Trong thư mục này, có rất nhiều file của từng người dùng của công ty hosting. Nó chứa rất nhiều thông tin nhạy cảm như là :

Các file .psd/.ai (Bản thô của những thiết kế, bí mật công ty)Các file cookies sqliteHoá đơnEbook lậuThông tin truy cập Wifi SSIDs

Những điều Hacker có thể hành động lúc này:

Đứng gần văn phòng của công ty hosting, đăng nhập vào mạng intranet của họ bằng các thông tin SSIDs đã lấy được và thực hiện toàn bộ các kiểu tấn công như ở mạng local (ví dụ MITM) mà các hệ thống giám sát IDS, FW đã trust(tin tưởng) IP/ userDump các nội dung nhạy cảm ở trên và đăng lên public domain.

4. Đòn Chí Mạng————————-

Sau khi lượn lờ một vài vòng với danh nghĩa user apache, tôi quyết định sẽ bắt một mẻ lớn, hay còn gọi là chiếm quyền truy cập root. Tôi tham khảo từ Cheatsheet phổ biến này và bắt đầu tìm kiếm các file hệ thống để thịt.

Trong quá trình đào bới, tôi đã vận dụng hầu hết các kỹ năng có thể nhưng vẫn không thể tìm ra thứ gì khả dĩ để có thể nâng bước chân của mình lên một tầm cao mới.

Xem thêm: 4 Cách Thay Đổi Địa Chỉ Wordpress Mà Không Ảnh Hưởng Tới Seo

Và đó là lúc mà tôi gặp nhớ ra cái này. Trong một lần chơi CTF (Capture the Flag), hệ thống thường xuyên được cập nhật và thỉnh thoảng có một vài lỗi server được cố tình thiết lập sai để có thể cung cấp cho bạn quyền root nếu tìm ra chúng. Tuy nhiên trong thực tế, người ta không cập nhật hệ thống.Đầu tiên tôi kiểm tra Linux mà hệ thống đang dùng:


Và phiên bản của kernel là?


Ngay lập tức tôi đã viết mail và thông báo đến những ảnh hưởng mà cuộc tấn công của tôi có thể gây ra với từng step được mô tả kĩ lưỡng như ở trên, và khép lại một đêm thú vị.Lúc này, tổng kết lại, thì kẻ tấn công có thể làm được những thứ sau đây:

Đọc/thay đổi TOÀN BỘ file trên serverĐể lại backdoor (giống như với user apache)Cài và phát tán malware đến mạng intranet của server của toàn bộ công tyCài ransomware đòi tiền chuộcDùng server để đào tiền ảoDùng server như proxyDùng server như là một C2C serverDùng server cho botnet… Tuỳ các bạn tưởng tượngrm -rf /

Ngày hôm sau, bạn của tôi đã liên lạc lại và thông báo rằng lỗi upload file đã được fix.tl;dr (tóm lại)Tổng kết lại, chúng ta đã tìm thấy:

Một web app có lỗ hổng ở phần upload file sẽ dẫn đến việc tạo ra một webshell với quyền truy cập cấp thấpThông tin truy cập vào mysql database, dẫn đến khả năng đọc/ghi đến 35 database.Rất nhiều file thông tin nhạy cảm

Và chúng ta cũng có thể tận dụng việc kernel chưa được update để chiếm quyền truy cập root.

6. Thuốc giải————————-


Hãy bắt đầu với lỗi upload file khiến cho chúng ta có quyền truy cập vào shell của server. Bởi vì toàn bộ phần backend của web app được viết bằng Perl – trong khi tôi không sử dụng Perl nên tôi không thể đưa ra được giải pháp gì cho phần này.Có một vấn đề mà tôi có thể đề nghị được, đó là không dùng Perl ở năm 2017, nhưng đó chỉ là ý kiến chủ quan và hoan nghênh các bạn chứng minh rằng tôi sai.Ngoài ra, việc chạy tất cả các website trên cùng 1 server là một ý tưởng tồi , nhưng tôi cũng không chắc rằng sử dụng docker có giải quyết được vấn đề một cách triệt để hay không.Cả việc thông tin truy cập cho tất cả db giống nhau cũng là một vấn đề nên tránh.Cuối cùng, thường xuyên Cập nhật mọi thứ. Nó chỉ là một câu lệnh mà thôi su -c ‘yum update’ (dành cho CentOS).

Có thể bạn quan tâm: