Cách tin tặc chiếm lấy các trang web với SQL Injection và DDoS

Ngay cả khi bạn chỉ theo dõi các sự kiện của nhóm hacker Anonymous và LulzSec một cách lỏng lẻo, có lẽ bạn đã nghe nói về các trang web và dịch vụ bị hack, như vụ hack khét tiếng của Sony. Bạn đã bao giờ tự hỏi làm thế nào họ làm điều đó?

Có một số công cụ và kỹ thuật mà các nhóm này sử dụng, và trong khi chúng tôi không cố gắng đưa cho bạn một hướng dẫn để tự làm điều này, thật hữu ích để hiểu những gì đang diễn ra. Hai trong số các cuộc tấn công mà bạn luôn nghe về chúng bằng cách sử dụng là từ chối (Phân phối) Từ chối dịch vụ (DDoS) và Tấn công SQL SQL (SQLI). Đây là cách họ làm việc.

Hình ảnh bởi xkcd

Tấn công từ chối dịch vụ

Nó là gì?

Một cuộc tấn công từ chối dịch vụ của người dùng (đôi khi được gọi là một cuộc tấn công từ chối dịch vụ phân phối hoặc dịch vụ phân phối của người dùng), khi một hệ thống, trong trường hợp này là một máy chủ web, nhận được rất nhiều yêu cầu tại một thời điểm mà tài nguyên máy chủ bị quá tải, hệ thống chỉ bị khóa và tắt. Mục tiêu và kết quả của một cuộc tấn công DDoS thành công là các trang web trên máy chủ mục tiêu không có sẵn cho các yêu cầu lưu lượng hợp pháp.

Làm thế nào nó hoạt động?

Hậu cần của một cuộc tấn công DDoS có thể được giải thích tốt nhất bằng một ví dụ.

Hãy tưởng tượng một triệu người (những kẻ tấn công) kết hợp với mục tiêu cản trở việc kinh doanh của Công ty X bằng cách hạ gục trung tâm cuộc gọi của họ. Những kẻ tấn công phối hợp để vào thứ ba lúc 9 giờ sáng, tất cả chúng sẽ gọi số điện thoại của Công ty X. Nhiều khả năng, hệ thống điện thoại của Công ty X sẽ không thể xử lý một triệu cuộc gọi cùng một lúc nên tất cả các đường dây đến sẽ bị trói bởi những kẻ tấn công. Kết quả là các cuộc gọi của khách hàng hợp pháp (tức là những cuộc gọi không phải là kẻ tấn công) không được thực hiện do hệ thống điện thoại bị trói xử lý các cuộc gọi từ những kẻ tấn công. Vì vậy, về bản chất, Công ty X có khả năng mất việc kinh doanh do các yêu cầu hợp pháp không thể thực hiện được.

Một cuộc tấn công DDoS trên máy chủ web hoạt động chính xác theo cùng một cách. Vì hầu như không có cách nào để biết lưu lượng truy cập nào có nguồn gốc từ các yêu cầu hợp pháp so với kẻ tấn công cho đến khi máy chủ web xử lý yêu cầu, loại tấn công này thường rất hiệu quả.

Thực hiện cuộc tấn công

Do tính chất vũ phu của người dùng trong cuộc tấn công DDoS, bạn cần phải có rất nhiều máy tính phối hợp để tấn công cùng một lúc. Xem lại ví dụ về trung tâm cuộc gọi của chúng tôi, điều này sẽ yêu cầu tất cả những kẻ tấn công phải biết gọi vào lúc 9 giờ sáng và thực sự gọi vào thời điểm đó. Mặc dù nguyên tắc này chắc chắn sẽ hoạt động khi tấn công máy chủ web, nhưng nó trở nên dễ dàng hơn đáng kể khi máy tính zombie, thay vì máy tính có người lái thực sự, được sử dụng.

Như bạn có thể biết, có rất nhiều biến thể của phần mềm độc hại và trojan, mà một lần trên hệ thống của bạn, nằm im lìm và thỉnh thoảng điện thoại về nhà điện thoại để được hướng dẫn. Ví dụ, một trong những hướng dẫn này có thể là gửi các yêu cầu lặp lại đến máy chủ web của Công ty X lúc 9 giờ sáng. Vì vậy, với một bản cập nhật duy nhất cho vị trí nhà của phần mềm độc hại tương ứng, một kẻ tấn công có thể ngay lập tức phối hợp hàng trăm ngàn máy tính bị xâm nhập để thực hiện một cuộc tấn công DDoS lớn.

Vẻ đẹp của việc sử dụng máy tính zombie không chỉ ở tính hiệu quả mà còn ở tính ẩn danh vì kẻ tấn công thực sự không phải sử dụng máy tính của họ để thực hiện cuộc tấn công.

Tấn công SQL SQL

Nó là gì?

Tấn công SQL SQL (SQLI) tấn công là một khai thác lợi dụng các kỹ thuật phát triển web kém và thường được kết hợp với bảo mật cơ sở dữ liệu bị lỗi. Kết quả của một cuộc tấn công thành công có thể bao gồm từ mạo danh tài khoản người dùng đến thỏa hiệp hoàn toàn cơ sở dữ liệu hoặc máy chủ tương ứng. Không giống như một cuộc tấn công DDoS, một cuộc tấn công SQLI hoàn toàn và dễ dàng ngăn chặn được nếu một ứng dụng web được lập trình phù hợp.

Thực hiện cuộc tấn công

Bất cứ khi nào bạn đăng nhập vào một trang web và nhập tên người dùng và mật khẩu của bạn, để kiểm tra thông tin đăng nhập của bạn, ứng dụng web có thể chạy một truy vấn như sau:

CHỌN UserID TỪ người dùng WHERE UserName = "myuser" VÀ Password = "mypass";

Lưu ý: các giá trị chuỗi trong truy vấn SQL phải được đặt trong các dấu ngoặc đơn, đó là lý do tại sao chúng xuất hiện xung quanh các giá trị được nhập của người dùng.

Vì vậy, sự kết hợp giữa tên người dùng đã nhập (myuser) và mật khẩu (mypass) phải khớp với một mục trong bảng Người dùng để trả lại ID người dùng. Nếu không có kết quả trùng khớp, không có UserID nào được trả về để thông tin đăng nhập không hợp lệ. Trong khi một triển khai cụ thể có thể khác nhau, cơ học là khá chuẩn.

Vì vậy, bây giờ hãy xem xét một truy vấn xác thực mẫu mà chúng ta có thể thay thế các giá trị mà người dùng nhập vào biểu mẫu web:

CHỌN UserID TỪ người dùng WHERE UserName = "[user]" AND Password = "[pass]"

Thoạt nhìn có vẻ như đây là một bước đơn giản và hợp lý để dễ dàng xác thực người dùng, tuy nhiên nếu việc thay thế đơn giản các giá trị người dùng nhập được thực hiện trên mẫu này, thì nó dễ bị tấn công SQLI.

Ví dụ: giả sử là my myuser'-iết được nhập vào trường tên người dùng và nhập sai lầm vượt qua được nhập vào mật khẩu. Sử dụng thay thế đơn giản trong truy vấn mẫu của chúng tôi, chúng tôi sẽ nhận được điều này:

CHỌN UserID TỪ người dùng WHERE UserName = "myuser" - 'AND Password = "mispass"

Chìa khóa cho tuyên bố này là sự bao gồm của hai dấu gạch ngang (-). Đây là mã thông báo nhận xét bắt đầu cho các câu lệnh SQL, vì vậy mọi thứ xuất hiện sau hai dấu gạch ngang (đã bao gồm) sẽ bị bỏ qua. Về cơ bản, truy vấn trên được cơ sở dữ liệu thực hiện dưới dạng:

CHỌN UserID TỪ người dùng WHERE UserName = "myuser"

Thiếu sót rõ ràng ở đây là thiếu kiểm tra mật khẩu. Bằng cách bao gồm hai dấu gạch ngang như một phần của trường người dùng, chúng tôi đã bỏ qua hoàn toàn điều kiện kiểm tra mật khẩu và có thể đăng nhập với tên là my myuser mà không cần biết mật khẩu tương ứng. Hành động thao túng truy vấn này để tạo ra kết quả ngoài ý muốn là một cuộc tấn công SQL SQL.

Những thiệt hại có thể được thực hiện?

Một cuộc tấn công tiêm nhiễm SQL được gây ra bởi mã hóa ứng dụng cẩu thả và vô trách nhiệm và hoàn toàn có thể phòng ngừa được (chúng tôi sẽ đề cập trong giây lát), tuy nhiên mức độ thiệt hại có thể được thực hiện tùy thuộc vào thiết lập cơ sở dữ liệu. Để ứng dụng web giao tiếp với cơ sở dữ liệu phụ trợ, ứng dụng phải cung cấp thông tin đăng nhập vào cơ sở dữ liệu (lưu ý, điều này khác với đăng nhập của người dùng vào chính trang web). Tùy thuộc vào quyền mà ứng dụng web yêu cầu, tài khoản cơ sở dữ liệu tương ứng này có thể yêu cầu mọi thứ từ quyền đọc / ghi trong các bảng hiện có cho đến quyền truy cập cơ sở dữ liệu đầy đủ. Nếu điều này không rõ ràng bây giờ, một vài ví dụ sẽ giúp cung cấp một số sự rõ ràng.

Dựa vào ví dụ trên, bạn có thể thấy điều đó bằng cách nhập, ví dụ, "youruser '-", "admin' -" hoặc bất kỳ tên người dùng nào khác, chúng tôi có thể đăng nhập ngay vào trang web với tư cách là người dùng đó mà không cần biết mật khẩu. Khi chúng tôi ở trong hệ thống không biết chúng tôi thực sự không phải là người dùng đó nên chúng tôi có quyền truy cập đầy đủ vào tài khoản tương ứng. Quyền truy cập cơ sở dữ liệu sẽ không cung cấp mạng an toàn cho việc này vì thông thường, một trang web phải có ít nhất quyền truy cập đọc / ghi vào cơ sở dữ liệu tương ứng của nó.

Bây giờ, giả sử trang web có toàn quyền kiểm soát cơ sở dữ liệu tương ứng của nó, cho phép xóa các bản ghi, thêm / xóa bảng, thêm tài khoản bảo mật mới, v.v. Điều quan trọng cần lưu ý là một số ứng dụng web có thể cần loại quyền này vì vậy nó không phải tự động là một điều xấu mà toàn quyền được cấp.

Vì vậy, để minh họa thiệt hại có thể được thực hiện trong tình huống này, chúng tôi sẽ sử dụng ví dụ được cung cấp trong truyện tranh ở trên bằng cách nhập thông tin sau vào trường tên người dùng: "Robert '; DROP TABLE Người dùng; -". Sau khi thay thế đơn giản, truy vấn xác thực trở thành:

CHỌN UserID TỪ người dùng WHERE UserName = "Robert"; Người dùng DROP TABLE; - 'AND Password = "mispass"

Lưu ý: dấu chấm phẩy nằm trong truy vấn SQL được sử dụng để biểu thị sự kết thúc của một câu lệnh cụ thể và phần đầu của một câu lệnh mới.

Mà được thực hiện bởi cơ sở dữ liệu như:

CHỌN ID người dùng TỪ người dùng WHERE UserName = "Robert"

Người dùng DROP BẢNG

Vì vậy, như vậy, chúng tôi đã sử dụng một cuộc tấn công SQLI để xóa toàn bộ bảng Người dùng.

Tất nhiên, điều tồi tệ hơn có thể được thực hiện là, tùy thuộc vào các quyền SQL được phép, kẻ tấn công có thể thay đổi giá trị, kết xuất bảng (hoặc toàn bộ cơ sở dữ liệu) thành tệp văn bản, tạo tài khoản đăng nhập mới hoặc thậm chí chiếm quyền điều khiển toàn bộ cơ sở dữ liệu.

Ngăn chặn một cuộc tấn công SQL SQL

Như chúng tôi đã đề cập nhiều lần trước đây, một cuộc tấn công tiêm SQL có thể dễ dàng ngăn chặn được. Một trong những quy tắc chính của phát triển web là bạn không bao giờ tin tưởng một cách mù quáng vào đầu vào của người dùng như chúng tôi đã làm khi chúng tôi thực hiện thay thế đơn giản trong truy vấn mẫu của chúng tôi ở trên.

Một cuộc tấn công SQLI dễ dàng bị cản trở bởi những gì được gọi là vệ sinh (hoặc thoát) các đầu vào của bạn. Quá trình khử trùng thực sự khá tầm thường vì tất cả những gì nó thực hiện là xử lý bất kỳ ký tự trích dẫn nội tuyến nào (') một cách thích hợp sao cho chúng không thể được sử dụng để chấm dứt sớm một chuỗi bên trong câu lệnh SQL.

Ví dụ: nếu bạn muốn tìm kiếm trong phần cơ sở dữ liệu, bạn không thể sử dụng thay thế đơn giản vì trích dẫn đơn sau chữ O sẽ khiến chuỗi kết thúc sớm. Thay vào đó, bạn vệ sinh nó bằng cách sử dụng ký tự thoát của cơ sở dữ liệu tương ứng. Giả sử ký tự thoát cho một trích dẫn nội tuyến đang mở đầu mỗi trích dẫn bằng ký hiệu \. Vì vậy, hoàng tử O'neal phạm sẽ được vệ sinh như là.

Hành động đơn giản này của vệ sinh khá nhiều ngăn chặn một cuộc tấn công SQLI. Để minh họa, hãy xem lại các ví dụ trước của chúng tôi và xem các truy vấn kết quả khi đầu vào của người dùng được vệ sinh.

người dùng của tôi-- / sai:

CHỌN UserID TỪ người dùng WHERE UserName = "myuser \" - 'AND Password = "mispass"

Vì trích dẫn duy nhất sau khi myuser được thoát (có nghĩa là nó được coi là một phần của giá trị đích), nên cơ sở dữ liệu sẽ tìm kiếm theo đúng Tên người dùng của "người dùng của tôi '-". Ngoài ra, vì các dấu gạch ngang được bao gồm trong giá trị chuỗi chứ không phải chính câu lệnh SQL, chúng sẽ được coi là một phần của giá trị đích thay vì được hiểu là một nhận xét SQL.

Robert '; Người dùng DROP BẢNG;-- / sai:

CHỌN UserID TỪ người dùng WHERE UserName = "Robert \"; Người dùng DROP TABLE; - 'AND Password = "mispass"

Bằng cách đơn giản thoát khỏi dấu ngoặc đơn sau Robert, cả dấu chấm phẩy và dấu gạch ngang đều được chứa trong chuỗi tìm kiếm UserName để cơ sở dữ liệu sẽ tìm kiếm theo nghĩa đen "Robert '; DROP TABLE Người dùng; -" thay vì thực hiện xóa bảng.

Tóm tắt

Mặc dù các cuộc tấn công web phát triển và trở nên tinh vi hơn hoặc tập trung vào một điểm xâm nhập khác, điều quan trọng cần nhớ là phải bảo vệ chống lại các cuộc tấn công đã cố gắng và thực sự, vốn là nguồn cảm hứng của một số công cụ tin tặc có sẵn miễn phí..

Một số loại tấn công, chẳng hạn như DDoS, không thể dễ dàng tránh được trong khi các loại tấn công khác, chẳng hạn như SQLI, có thể. Tuy nhiên, thiệt hại có thể gây ra bởi các loại tấn công này có thể dao động ở mọi nơi từ bất tiện đến thảm khốc tùy thuộc vào các biện pháp phòng ngừa được thực hiện.