Tôi Đã Hack 40 Trang Web Trong Vòng 7 Phút Như Thế Nào ?

Một người bạn đã nhắn tin cho tôi rằng có một lỗi về đã đượ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&# 224; anh ấy đã .

Bước đầu tiên (mà tôi luôn thực hiện khi hack) là liệt kê và tìm kiếm càng nhiều thông tin càng tốt về mục tiêu của mình - trong khi tránh gây chú ý hết mức có thể.

Ở bước này tôi đã bật bộ đếm thời gian và bắt đầu quét.

$ nmap --top-ports 1000 -T4 -sC example.com  Nmap scan report for chúng tôi {redacted}  Host is up (0.077s latency).  rDNS record for {redacted}: {redacted}  Not shown: 972 filtered ports  PORT      STATE  SERVICE  21/tcp    open   ftp  22/tcp    open   ssh  | ssh-hostkey:  |   {redacted}  80/tcp    open   http  | http-methods:  |_  Potentially risky methods: TRACE  |_http-title: Victim Site  139/tcp   open   netbios-ssn  443/tcp   open   https  | http-methods:  |_  Potentially risky methods: TRACE  |_http-title: Site doesn't have a title (text/html; charset=UTF-8).  |_{redacted}  445/tcp   open   microsoft-ds  5901/tcp  open   vnc-1  | vnc-info:  |   Protocol version: 3.8  |   Security types:  |_    VNC Authentication (2)  8080/tcp  open   http-proxy  |_http-title: 400 Bad Request  8081/tcp  open   blackice-icecap

Có khá nhiều port đang được mở trên Server! Bằng việc quan sát thấy rằng cổng FTP (21) và SMB (139/445) đang mở, chúng ta có thể đoán được server này được sử dụng để lưu trữ và chia sẻ file, đồng thời được sử dụng như một Webserver (cổng 80/443 và proxies 8080/8081)

Để không tốn thời gian hack, tôi sử dụng để quét một số file có vẻ trên Webserver, trong khi tiếp tục tìm kiém thêm thông tin thủ công.

$ gobuster -u example.com -w chúng tôi -t 100  /admin  /login

Kết quả nhận được là đường dẫn admin/ là nơi chứa "admin tool" dành cho người dùng đã xác thực có thể thay đổi các thành phần trên Webserver. Công cụ này yêu cầu thông tin đăng nhập trong khi chúng ta không có cả username lẫn password, nên tạm thời sẽ để ở đó (thực tế là gobuster chả tìm được gì thú vị cả).

Khi truy cập vào website, tôi thấy rằng nó yêu cầu đăng nhập. Không vấn đề, tôi tạo một tài khoản với email rác, bấm vào link xác nhận trên email và đăng nhập chỉ trong vài giây.

Trang web mở giao diện chào mừng và hỏi tôi có muốn đến trang profile và cập nhật ảnh đại diện hay không. Thật nồng hậu biết bao!

Để ý thấy rằng giao diện của website đã custom lại giao diện, tôi quyết định thử với một kiểu tấn công có tên là Unrestricted File Upload - Upload file không an toàn . Ở terminal tôi tạo ra một file như sau:

Sau đó tôi thử upload file phía trên, và File chúng tôi đã được upload lên server. Tất nhiên là nó không có thumbnail, tuy nhiên điều đó có nghĩa là file của tôi đã được lưu ở đâu đó trên server.

Ta tưởng rằng khi upload file lên server, sẽ có một vài process , thay thế chúng thành các định dạng được chấp nhận như , để tránh việc thực hiện code bởi kẻ tấn công khi upload một file chứa mã độc.

`Copy image address` results in the following url being copied to our clipboard:  example.com/admin/ftp/objects/XXXXXXXXXXXX.php

Điều khiến tôi bất ngờ nhất là, server không chỉ được dùng để host 1 mà tới những . Thật buồn là tôi đã không lưu lại ảnh chụp của từng website một nhưng output thì kiểu như này:

​

Bạn vừa biết là chúng ta đã có cái gì rồi đấy. Thật bất ngờ là chúng ta có thể đọc được mã nguồn của các website đang được host trên server.

Một điều đáng chú ý nữa là, ở trong thư mục , tất cả perl script đều được kết nối với một với quyền . Đồng thời và để truy cập cũng lồ lộ ở đây dưới dạng (cleartext). Ví dụ như username/password là root: pwned42.

Có thể chắc chắc rằng server sử dụng và tôi đã phải tham khảo issue này trước khi có thể truy cập được vào DB. Sau cùng khi thực hiện lệnh:

mysql -u root -p -h localhost victimdbname  Password: pwned42

Chúng ta đã ở trong Database với người dùng root:

Sử dụng lệnh " ; sẽ cho phép chúng ta truy cập bất kỳ db nào trong số 35 db này và xem và sửa nội dung của chúng.

1. Dump nội dung của tất cả các database, khiến cho dữ liệu của 35 công ty publish trên các domain công cộng.
2. Xoá tất cả các database, xoá sổ dữ liệu của toàn bộ 35 công ty
3. Để lại một cửa sau (backdoor) để có thể truy cập mọi lúc dưới tên apache cùng với cronjob, bằng cách thức ví dụ như thế này, khi có nhu cầu quay trở lại.

:

• 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 sqlite
• Hoá đơn
• Ebook lậu
• Thông tin truy cập Wifi SSIDs

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

1. Đứ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/ user
2. Dump các nội dung nhạy cảm ở trên và đăng lên public domain.

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 . 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.

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 , người ta cập nhật hệ thống.

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.(tóm lại)với quyền truy cập cấp thấp

Thô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 để chiếm quyền truy cập .

1. Hãy bắt đầu với lỗi upload file khiến cho chúng ta có 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.
2. Có một vấn đề mà tôi có thể đề nghị được, đó là không dùng Perl ở năm 2025, nhưng đó chỉ là ý kiến chủ quan và hoan nghênh các bạn chứng minh rằng tôi sai.
3. Với phần filesystem, tôi đề nghị cần quản lý một cách , tốt nhất là bám sát theo nguyên tắc quyền tối thiểu. Bằng cách này, kể cả nếu user có quyền truy cập thấp như apache bị chiếm thì cũng không thể đọc bất kỳ thông tin nhạy cảm nào.
4. Ngoài ra, việc chạy tất cả các website trên cùng 1 server là một, nhưng tôi cũng không chắc rằng sử dụng có giải quyết được vấn đề một cách triệt để hay không.
5. Cả việc thông tin cũng là một vấn đề nên tránh.
6. 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).