Hướng dẫn hack 1 trang web đơn giản năm 2024

Lỗ hổng bảo mật trên code sẽ giúp Hacker thực hiện các phương pháp tấn công để chèn malware và website!

Trong Topic đầu tiên của chuyên đề Bảo mật Website – Khóa học Pro WP Master, chúng ta sẽ tìm hiểu các hình thức hack website phổ biến nhất hiện nay.

Từ đó, các topic sau chúng ta sẽ nhận diện hiện tượng Website bị hack – nguyên nhân và các phương pháp bảo mật mới nhất!

Chúng ta cũng sẽ làm chủ plugin bảo mật iThemes Security Free và Pro (trong VIP CLUB) để bổ sung các phương pháp bảo mật hiệu quả nhất cho WordPress.

Cuối chuyên đề sẽ là các phương pháp backup tự động và restore khi gặp sự cố – cũng như hướng dẫn quét malware và phục hồi Website WordPress bị nhiễm mã độc!

Mục lục bài viết

Hack Website là gì?

Hack là hành động thâm nhập trái phép vào phần cứng hoặc phần mềm.

Hack Website là xâm nhập trái phép vào Website, truy cập vào các khu vực mà người dùng bình thường không được phép như hosting, trang quản trị, soạn thảo…

Hack website cũng bao gồm hành động can thiệp vào mã nguồn, database và chỉnh sửa nội dung và thay đổi các tính năng của Website trái phép.

Mục đích Hack Website là gì?

Vào những năm đầu của kỷ nguyên Web, thì các tay hacker tấn công khai thác các lỗ hổng bảo mật trên Website mục đích chỉ để thể hiện số má – hoặc phá hoại, có thể để cảnh báo các lỗ hổng bảo mật mà quản trị web không biết.

Website sân bay Tân sơn nhất bị Hack

Bạn có thể thấy các vụ tấn công vào Website các chính phủ, tập đoàn hoặc tiêu biểu ở VN là tấn công vào Website của bộ Giáo dục & Đào tạo.

Các lỗ hổng bảo mật trên Website – dù dùng mã nguồn gì thì cũng luôn luôn tồn tại, vấn đề là nó có được phát hiện hay không thôi.

Đôi khi, các lỗ hổng bảo mật bắt nguồn từ các lỗi cực kỳ sơ đẳng, ví dụ như lưu thông tin đăng nhập trên máy tính, điện thoại rồi mang ra tiệm sửa, … hoặc lỗ hổng do code cẩu thả gây ra…

So với thời kỳ đầu, thì mục đích của Hack Website hiện nay 99% là vì tiền, như ăn cắp dữ liệu để bán lại, ăn cắp thông tin thẻ tín dụng/ ghi nợ để rút tiền, hack mướn cho các đối thủ cạnh tranh không lành mạnh, phát tán nội dung cho các thế lực xấu….

Và nhất là hack cho các mục đích kiếm tiền trực tiếp: chèn link chuyển hướng về site kiếm tiền, chèn nội dung lừa đảo, chèn quảng cáo, chèn link cho các chiến dịch Blackhat SEO…

Nhưng website đó không quan trọng?

Khi mới bắt đầu tạo Website, chúng ta thường nghĩ Web đó chỉ là web mẫu, có bị hack cũng không sao. Nhưng khi một website bị thâm nhập, hacker sẽ cài mã độc lên hosting và âm thầm lây nhiễm lên toàn bộ các Website khác sau này, ….

Khi một Website bị chiếm quyền, thì hacker có thể dùng các phương pháp tấn công Local Attack rất phổ biến để thực thi các lệnh tấn công toàn bộ các Website khác trên cùng gói Hosting.

Vô số tác hại xảy ra khi một website bảo mật kém nằm trên cùng hosting/vps với các Websites quan trọng khác, không chỉ lây nhiễm mã độc mà còn khiến nguy cơ các Website khác bị Google cấm cửa chỉ vì một site demo vô thưởng vô phạt bạn tạo ra trước đó.

Dù cách thức thực hiện hack Website vô cùng đa dạng, nhưng chung qui, có các hình thức phổ biến chiếm hầu hết các vụ tấn công bảo mật!

Có 2 kiểu tấn công là:

1. Access Control: tìm cách truy cập trái phép vào tài khoản quản trị hosting/vps hay website bằng cách dò thông tin đăng nhập. Tiêu biểu là cách tấn công website nổi tiếng Brute Force Attack.
2. Software Vulnerabilities – Code Injection: khai thác lỗ hổng bảo mật trên phần mềm, code để tấn công vào website, cài các phần mềm độc hại (malware) để thực hiện các tác vụ xấu. Tiêu biểu loại này là SQL Injection (SQLi), tấn công XSS, LFI (Local File Inclusion) và RFI (Remote File Inclusion).

Dù là kiểu tấn công nào, thì cuối cùng, kết quả thường là Website của bạn sẽ bị chèn mã độc, để hacker có thể để lại một backdoor cho phép họ thâm nhập sau này, hoặc mã độc âm thầm thực hiện các tác vụ gây hại trên website.

Chúng ta sẽ tìm hiểu về Mã độc trên Website – Malware trong topic tiếp theo.

1. Tấn công Dò mật khẩu – Brute Force Attack

Đây là kiểu tấn công tưởng là cơ bản – nhưng hiệu quả cao nhất.

Brute Force Attack là gì?

Brute Force Attack là kiểu tấn công bằng phương pháp dò mật khẩu, với các thuật toán tự động thử các chuỗi mật khẩu khác nhau, bao gồm số, chữ cái – chữ cái & số….

Về lý thuyết, nếu có đủ thời gian, thì Brute Force cuối cùng sẽ tìm được mật khẩu chính xác.

Không phải như nhiều người nghĩ Brute Force Attack là ‘đoán’ mật khẩu, mà thực tế có các chương trình với thuật toán dò mật khẩu ‘máu lạnh’ – với xác xuất bắt được các mật khẩu yếu rất cao.

Nếu bạn dùng tài khoản kiểu admin/ password, admin/ 123456, admin/ 123abc… thì xem như cúng Website cho Hacker rồi.

Để check xem thời gian trung bình dò một mật khẩu, bạn có thể kiểm tra ở đây:

Password check – Kespersky Lab

Với một phần mềm mà hacker nào cũng có thể viết hoặc tìm được trên mạng, được hacker cung cấp một dải IP hay danh sách domain lấy từ các nguồn có sẵn, thì danh sách Website bị thâm nhập nhiều như lá mùa thu, tất cả bắt nguồn từ thói quen tạo tài khoản rất ngây thơ mà vẫn còn một số lượng lớn người dùng mắc phải.

Brute Force Attack qua XML-RPC trên WordPress

Thông thường phương thức tấn công dò mật khẩu Brute Force Attack được thực hiện bằng cách gởi thông tin username/ password trực tiếp tới trang đăng nhập WordPress, mặc định là ten-mien/wp-admin hoặc ten-mien/wp-login.php.

Để phòng chống, chúng ta thường đổi đường dẫn đăng nhập (dùng plugin iThemes Security chẳng hạn), hoặc thêm tính năng mật khẩu 2 lớp (Two Factor Authentication), hoặc thêm Captcha checkbox….

Nhưng, còn một kiểu Brute Force Attack khác, đó là qua XML-RPC!

Tấn công Brute Force Attack qua XML-RPC. Nguồn Sucuri blog

XML-RPC là gì?

XML-RPC là một giao thức gọi thủ tục từ xa, cho phép thực hiện các request HTTP theo một tập lệnh XML được mã hóa.

Điểm đặt biệt là của XML-RPC là phương thức system.multicall, cho phép gởi nhiều tổ hợp tham số trong mỗi request.

XML-RPC không chỉ dùng trong WordPress mà còn hỗ trợ trên nhiều CMS và ngôn ngữ lập trình Web phổ biến khác. XML-RPC hiện nay không còn quá cần thiết, chỉ có một số ít plugin còn cần tính năng này (như Jetpack). Nhưng nó hiện vẫn được kích hoạt tự động trong WordPress Core.

Trong WordPress, XML-RPC là tính năng cho phép kết nối với WordPress từ các ứng dụng bên ngoài để đăng bài (như WordPress Apps trên Apple App Store..)

Đây là tính năng có từ thời việc kết nối Internet còn chậm, người dùng soạn thảo sẵn bài viết trên máy tính và dùng XML-RPC để kết nối với Website và đăng bài thay vì mở trình duyệt web và soạn thảo trực tiếp như hiện nay.

Từ năm 2015, hacker đã lợi dụng phương thức system.multicall của XML-RPC để thực hiện các truy vấp dò mật khẩu quản trị.

Nôm na là, hacker sẽ gởi tới XML-RPC một lệnh wp.getCategories để truy xuất dữ liệu danh mục – để thực hiện lệnh này, đòi hỏi phải login quyền Adminstrator, lợi dụng phương thức system.multicall mà XML-RPC hỗ trợ, hacker có thể gởi kèm lệnh đó cùng với hàng trăm cặp username/password khác nhau.

Như vậy, chỉ mỗi một HTTP request tới XML-RPC, hacker sẽ thử được đến vài trăm cặp user/pass, nên phương thức tấn công này có cường độ gấp trăm lần so với cách tấn công Brute Force Attack qua trang login (ten-mien/wp-admin, ten-mien/wp-login.php,…).

Cách tấn công này cũng không thể chặn bằng phương pháp đổi đường dẫn đăng nhập hoặc Two Authentication, Captcha Checkbox… Vì tính năng XML-RPC khi bật có thể gởi request trực tiếp mà không cần qua bất cứ lớp bảo mật thông thường nào.

Vì cường độ tấn công lớn, lỗ hổng XML-RPC còn được dùng cho mục đích tấn công từ chối dịch vụ (DDos).

Để chống tình trạng này, chúng ta sẽ cần tắt XML-RPC thủ công từ hosting, hoặc tắt một phần – chặn system.multicall bằng các plugin.

Việc này sẽ được hướng dẫn chi tiết trong topic các phương pháp bảo mật trong cùng chuyên đề này.

2. Tấn công vào các lỗ hổng bảo mật trên Hosting

Có vô số các dịch vụ Hosting/ VPS giá rẻ như cho trên thị trường, với thông số quảng cáo hoành tráng – nhưng đằng sau đó đôi khi chỉ là một ‘tay mơ’ thuê máy chủ để bán hosting hoặc mua các gói reseller hosting chất lượng thấp bán lại.

Các công nghệ bảo mật trên hosting đòi hỏi đầu tư tiền bạn và phải có chuyên môn kỹ thuật, giàu kinh nghiệm mới đảm bảo được.

Hosting không chỉ có tài nguyên phần cứng, mà các công nghệ đảm bảo an toàn cho Website càng quan trọng hơn nhiều.

Nếu một máy chủ, vps hoặc gói hosting bị hacker thâm nhập, thì mọi cách thức bảo mật trên Website trở nên vô nghĩa.

Tai hại ở chỗ, nếu Website bị nhiễm malware trên hosting cũ, bạn move qua hosting mới mà chưa gỡ sạch mã độc trong code và database thì mọi thứ vẫn không khác gì.

3. Hack lỗ hổng bảo mật trên Code

Tấn công bảo mật Code Injection – nguồn researchgate.net

Đây là cách thức tấn công Website phổ biến nhất, nó là nguyên nhân chính khiến cho ‘bảo mật Website’ là cuộc chiến trường kỳ, không bao giờ có EndGame.

Mọi ngôn ngữ lập trình đều có điểm mạnh, điểm yếu nên luôn có các phương thức bảo mật để tránh bị hacker lợi dụng.

Vấn đề là các phần mềm, mã nguồn website không thể tự tạo ra mà được code bằng ‘cơm’, nên những lỗ hổng bảo mật – từ sơ đẳng đến hiếm gặp ngày ngày được tạo ra.

Làm developer có dễ không?

Một bạn mới học lập trình, nảy ra ý tưởng về một app với tính năng ‘thú vị’, bèn code ngay và đưa nó lên Store, nhiều người thấy app thú vị nên tải về dùng.

Một anh chàng mới học làm Web WordPress, nghĩ ra một tính năng hay, code ngay một plugin và share cho cộng đồng dùng. Thấy plugin gọn nhẹ mà hay, nhiều người cài đặt và sử dụng một cách thích thú…

Nhưng, code không đơn giản chỉ là thực thi ‘tính năng nào đó’ như mọi người tưởng. Cùng một tính năng, nhưng nếu không hiểu về các cơ chế bảo mật trong lập trình, chúng ta hoàn toàn có thể tạo ra các lỗ hổng để hacker tấn công vào Website.

Bad Developer – Nguồn Medium

Rất nhiều ứng dụng, addons/ plugins/ extension… được tạo ra từ những developer tay mơ, kèm theo đó là những lỗi sơ đẳng về bảo mật, xử lý hiệu năng và các lỗi tương thích…

Với người dùng bình thường, họ chỉ quan tâm tới tính năng hay chứ đâu cần biết nó có an toàn không.

Trong thế giới WordPress, hàng triệu Website vẫn vô tư dùng các plugin chỉ có vài reviews trên WP Repository, những plugin được chia sẻ trong những nhóm người dùng nhỏ (ví dụ các plugin do người dùng VN tạo ra để thêm tính năng cho Woo, Flatsome…).

Superman cũng là con người

Mọi Coder đều có lúc bất cẩn, chủ quan. Chưa kể có những vấn đề phát sinh từ thực tế sử dụng nên lỗ hổng bảo mật trong Code luôn luôn xuất hiện.

Superman cũng là con người nguồn http://itsfunny.org

Vô số các trang Web lớn (kể cả web của Nhà Trắng) gặp sự cố bảo mật, như Facebook gần đây – hacker lợi dụng một số tính năng để ăn cắp – xâm phạm data của người dùng.

Trong WordPress, từ mã nguồn WordPress core, các theme khủng Newspaper by Tagdiv, Porto, Avada hay các plugin Revolution Slider, Contact Form 7, Fancy Box… đều từng có những lỗi bảo mật nghiêm trọng.

Nên cái quan trọng nhất không phải là chọn CMS, theme, plugin… nào không có lỗi bảo mật – mà là “lỗi bảo mật xuất hiện khi nào và cách nào để phòng tránh – khắc phục lỗi bảo mật”

Để hiểu hơn về tấn công vào lỗ hổng bảo mật trên mã nguồn, chúng ta sẽ điểm qua các phương pháp tấn công phổ biến nhât nhiện nay qua lỗi bảo mật trên code.

3.1 SQL Injection (SQLi)

Dựa vào lỗi bảo mật trong code truy vấn cơ sở dữ liệu SQL, hacker chỉ cần cố tình sử dụng các giá trị và truy vấn đặc biệt để truy xuất – chỉnh sửa – thêm – xóa các dữ liệu trong database.

Trong hình là một ví dụ về tấn công lỗ hổng SQL, khi code không có cơ chế kiểm tra bảo mật chặc chẽ, truy vấn với tham số luôn đúng “1=1” sẽ khiến server trả về tất cả các kết quả hiện có trên database.

SQL Injection Attack – Nguồn CloudFlare

Lỗi SQL Injection chiếm một tỉ lệ lớn trong các vụ hack website, và gây ra tác hại rất nghiêm trọng vì khi can thiệp được vào database, hacker gần như nắm toàn quyền kiểm soát website của bạn.

Các cuộc tấn công SQL Injection nổi tiếng

Hầu hết các CMS phổ biến đều đã từng dính các lỗi SQLi, như Magento core, Joomla, Drupal… và vBulleting.

Trong WordPres, gần đây các plugin nổi tiếng như Duplicate Page, Ninja Form, Advanced Custom Form 7 DB, bbPress,…

Nổi tiếng nhất là các cuộc tấn công diện rộng vào lỗ hổng SQLi trên WP Statistics và WP NextGEN Gallery năm 2017, gây ảnh hưởng cả trăm nghìn Websites.

3.2 Cross-Site Scripting (XSS)

Kiểu tấn công này nhằm vào lỗ ổng bảo mật trên code, nhưng dùng các lệnh thực thi phía Client Site (phía người dùng).

Tấn công XSS – nguồn aioncloud. com

Các lệnh mà Hacker dùng thường là các ngôn ngữ client side như Javascript(JS), VBScript hay Flash, HTML… hiện nay thì phổ biến nhất là JS và HTML.

Mục đích của các đoạn mã JS, HTML là:

1. Ăn cắp cookie của người dùng: cookie này dùng để xác thực danh tính khi đăng nhập vào tài khoản trên các website, có được cookie này, hacker có thể hack vào tài khoản của bạn trên các website đang đăng nhập.
2. Lừa đảo (Pishing): đưa các nội dung lừa đảo vào một trang web để lừa người dùng nhập thông tin cá nhân, hoặc thực hiện các yêu cầu khác (như gởi tiền vào tk nào đó hoặc click vào các link độc hại…)

Các loại XSS Attack

Reflected XSS (non – persistant)

Hacker llừa người dùng nhấp vào các đường link của website họ đang đăng nhập.

Ví dụ người dùng đang đăng nhập vào vietcombank.com.vn, thì hacker sẽ gởi cho họ một đường link tương tự nhưng kèm các tham số để thực thi lện js do hacker tạo ra.

Cụ thể “https://vietcombank.com.vn/+ js code”

Nếu trang web được code kém bảo mật, không check và làm sạch các tham số trên ULR, thì các lệnh “js code” của hacker sau khi được xử lý bởi Server sẽ trả về trình duyệt thực thi ngay trên trình duyệt của người dùng, và lệnh “js code” này thường có nhiệm vụ ăn cắp và gởi cookie trên trình duyệt tới server của hacker.

Có cookie này hacker sẽ login vào chính tài khoản của người dùng trên vietcombank.com.vn mà không cần phải có username & mật khẩu.

Tất nhiên cookie chỉ còn hiệu lực nếu phiên làm việc (session) của người dùng vẫn còn, nếu người dùng đã đăng xuất khỏi vietcombank.com.vn trước khi nhấp vào link do hacker gởi thì cookie đó không còn sử dụng để login được nữa.

Cách tấn công này phụ thuộc vào trình độ ‘lừa’ của hacker và sự bất cẩn từ người dùng!

Stored XSS

Stored XSS là kiểu tấn công mà các đoạn mã js được chèn vào code, database của Website luôn. Khi người dùng truy cập vào các tác vụ tương ứng, mã js sẽ thực thi và đánh cắp cookie hoặc đưa các thông tin lừa đảo, redirect sang web xấu..

Kiểu tấn công này hiệu quả cao vì không cần lừa người dùng nhấp vào link nào cả, chỉ cần họ vào trang web có tác vụ bị gài mã js là ok.

Việc đưa mã độc js vào code/ database thường được thực hiện qua các tính năng cần lưu dữ liệu như Form liên hệ, khung bình luận, reviews….

Nếu quá trình code các tính năng này, developer không thực hiện các bước bảo mật như kiểm tra xác thực kiểu dữ liệu được nhập – loại bỏ các ký tự nguy hiểm… thì thay vì đưa các nội dung hợp pháp như nội dung bình luận, đánh giá… thì hacker sẽ nhập vào các đoạn mã js.

Trong WordPress, Stored XSS là lỗi được khai thác thường xuyên nhất, có thể kể đến WordPress phiên bản 5.0.x, Social Warfare, Jetpack, Akismet, bbPress…

DOM-based XSS

Một kỹ thuật tấn công XSS mới, cho phép hacker thay đổi cấu trúc DOM của trang web, khi người dùng nhấp vào phần nội dung thêm vào này, các đoạn mã js độc hại sẽ thực thi.

Nó tương tự với Reflected XSS nhưng thay vì gởi về Server để xử lý và phản hồi lại cho trình duyệt, thì DOM-based XSS thực thi ngay trên trình duyệt mà không cần phải gởi về Servers để xử lý lệnh.

Ví dụ hacker có thể gởi một đường link tới nạn nhân, nạn nhân click vào thì trên Website bị XSS sẽ có một Popup yêu cầu “nhập Password” để đăng nhập hoặc login để nhận phần thưởng chẳng hạn (mà thông tin bạn nhập vào sẽ gởi cho hacker thay vì gởi về server).

Tác hại của XSS Attack

Kỹ thuật XSS Attack & chống XSS Attack là một trong những kỹ thuật cơ bản trong bảo mật.

Lỗi XSS được tạo ra không phải bởi trình độ của developer non mà thường là do thói quen viết code cẩu thả, thiếu sự chuyên tâm.

Vì code bằng ‘cơm’ nên lỗi XSS có thể gặp ở bất kỳ coder nào, nên XSS attack vẫn còn là kiểu tấn công phổ biến – hiệu quả trong tương lai.

Nạn nhân trực tiếp của XSS Attack chính là người dùng, nhưng nạn nhân gián tiếp và bị ảnh hưởng nặng nề chính là Website dính lỗi XSS.

Người dùng sẽ quay lưng với Website sau khi bị tấn công, ăn cắp dữ liệu…

Nếu mã độc được đưa vào database (Stored XSS) thì Google và các trình duyệt sẽ cấm cửa luôn trang web hoặc toàn bộ Website.

3.3 Cross-Site Request Forgery (CSRF/ XSRF)

Cách thức tấn công CSRF dễ nhầm lẫn với XSS, vì nó dùng thủ đoạn lừa người dùng thực hiện một tác vụ mà chỉ có họ mới có quyền thực hiện.

Tuy nhiên, với XSS – kẻ tấn công thực hiện các lệnh bằng JS ngay trên trình duyệt người dùng. Còn với CSRF – kẻ tấn công gởi các lệnh tới để lừa người dùng thực hiện – các lệnh này có thể là các tác vụ thực hiện trên Server.

Cross Site Request Forgery – Nguồn Gbthackers

Ví dụ, bạn đang đăng nhập vào https://wpbanquyen.com, hacker sẽ gởi cho bạn một link như sau:

https://wpbanquyen.com/account?new_password=abc123

Sau khi nhấp vào link, bạn đã thực hiện đổi pass sang abc123 mà không hề biết, lệnh này chỉ có bạn khi đăng nhập mới có quyền thực thi. Thế là hacker dùng pass mới để login vào tài khoản của bạn.

Cách này cũng dùng để chiếm đoạt tiền. Ví dụ bạn đang login vào tài khoản ở ngân hàng Vietcombank, và khi đó, hacker bằng cách nào đó gởi cho bạn một đường link với một cái ảnh (được set kích thước 0.0 để ẩn tấm ảnh đi):

Khi nhấp vào link này, bạn thực hiện lệnh chuyển 1000 vào tài khoản vuihocweb trên cùng hệ thống ngân hàng Vietcombank…

Hiện nay các Website lớn đều có cơ chế chống tấn công CSRF, nhưng vẫn còn vô số lổ hổng để hacker lợi dụng, nên cuộc chiến bảo mật luôn rất căng thẳng.

Lỗi CSRF trên WordPress 5.0.x

Điển hình mới đây là phiên bản WordPress 5.0.x, lỗi CSRF cho phép hacker đăng tải một bình luận kèm đường link (tính năng pingback/trackpack). Nếu quản trị – Administrator nhấp vào đường link đó, sẽ thực thi các lệnh mà hacker muốn với quyền Administrator.

Lỗi bảo mật này còn có hiệu lực với những user quyền Editor. Vì các quyền Editor, Adminstrator có thể thực hiện các bình luận với các thẻ HTML như ,