1.3. MÃ HÓA CƠ SỞ DỮ LIỆU TRONG MICROSOFT SQL
1.3.2.2. Phương pháp thiết lập TDE
Để cho phép TDE, chúng ta phải có các quyền thơng thường được gắn kết với thao tác tạo một khóa chủ cơ sở dữ liệu (DMK – database master key) và các chứng chỉ trong cơ sở dữ liệu master. Chúng ta phải có các quyền CONTROL trên cơ sở dữ liệu người dùng.
Sau đây là các bước thực hiện trong cơ sở dữ liệu master:
• Nếu như khóa DMK khơng thực sự tồn tại, thì phải tạo một DMK cho cơ sở dữ liệu master. Đảm bảo rằng DMK được mã hóa bởi khóa chủ dịch vụ (SMK)
Sử dụng câu lện SQL sau để tạo khóa:
CREATE MASTER KEY ENCRYPTION BY PASSWORD = ‘some password’;
• Tạo hoặc chỉ định một chưngs chỉ đang có để sử dụng như là bộ bảo vệ khóa mã cơ sở dữ liệu (DEK). Để đạt được sự toàn cao nhất, chúng ta nên tạo một chứng chỉ mới chỉ có chức năng dùng để bảo vệ khóa DEK. Đảm bảo rằng chứng chỉ này được bảo vệ bởi DMK.
Mức hệ điều hành
Mức thể hiện SQL Server 2008
Cơ sở dữ liệu master
Cơ sở dữ liệu người dùng Khóa chủ dịch vụ
(Service Master Key)
Khóa chủ cơ sở dữ liệu
(Database Master Key)
Chứng chỉ lưu trong cơ sở dữ liệu master (Database Master Key) Khóa mã cơ sở dữ liệu
(Database Encryption Key)
Cơ sở dữ liệu master DP API
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
Sử dụng câu lệnh SQL sau để tạo chứng chỉ:
CREATE CERTIFICATE tdeCert WITH SUBJECT = ‘TDE Certificate’;
• Tạo một bản sao lưu dự phịng của chứng chỉ với khóa riêng đó và lưu giữ nó tại một nơi an tồn. Khóa riêng được lưu trong một tệp tin riêng biệt. Đảm bảo rằng giữ lại các bản sao của chứng chỉ khi dữ liệu có thể bị mất.
• Sử dụng câu lệnh SQL sau để tạo bản sao:
BACKUP CERTIFICATE tdeCert TO FILE = ‘path_to_file’ WITH PRIVATE KEY (
FILE = ‘path_to_private_key_file’,
ENCRYPTION BY PASSWORD = ‘cert password’);
• (Tùy chọn) Cho phép SSL trên server để bảo vệ dữ liệu trên đường truyền.
Thực hiện các bước tiếp theo trong cơ sở dữ liệu người dùng:
• Tạp khóa DEK được mã hóa bởi chứng chỉ được chỉ định ở bước trên. Chứng chỉ này được tham chiếu như là một chứng chỉ server để phân biệt nó với các chứng chỉ khác mà được lưu trong cơ sở dữ liệu người dùng.
Sử dụng câu lệnh SQL sau để tạo khóa DEK:
CREATE DATABASE ENCRYPTION KEY WITH ALGORITHM = AES_256
ENCRYPTION BY SERVER CERTIFICATE tdeCert
• Cho phép TDE, sử dụng lệnh:
ALTER DATABASE myDatabase SET ENCRYPTION ON
Để giám sát quá trình này, thực hiện truy vấn trên view (Yêu cầu có quyền VIEW SERVER STATE):
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
Ví dụ câu lệnh SQL:
SELECT db_name(database_id), encryption_state FROM sys.dm_database_encryption_keys 1.3.2.3. Phương pháp dữ liệu được mã hóa
Khi TDE được cho phép (hoặc bị cấm), cơ sở dữ liệu được đánh dấu là mã hóa trong view sys.databases và trạng thái DEK được thiết lập là “Encryption In Progress”. Server khởi động một luồng (thread), thực hiện quét tất cả các tệp tin cơ sở dữ liệu và mã hóa chúng (hoặc giải mã chúng nếu như TDE đang bị cấm). Trong khi câu lệnh DDL thực thi, một khóa cập nhật xuất hiện trên cơ sở dữ liệu đó. Bộ qt mã hóa, khơng chạy đồng thời với các lệnh DDL, tạo một khóa chia sẻ. Các hoạt động bình thướng khác mà khơng xung đột với các khóa này có thể được xử lý. Các hoạt động bị ngăn chặn bao gồm sửa đổi cấu trúc file, gỡ cơ sở dữ liệu.
Trong khi cơ sở dữ liệu ghi dữ liệu từ pool đệm ra đĩa thì dữ liệu này được mã hóa. Khi bộ qt mã hóa hồn thành, trạng thái DEK được thiết lập là Encrypted. Tại thời điểm này tất cả các tệp cơ sở dữ liệu trên đĩa được mã hóa và tệp cơ sở dữ liệu và nhật ký khi ghi ra đĩa được mã hóa. Các thuật tốn mã hóa được hỗ trợ là AES với 128 bit, 192 bit, 256 bit khóa hoặc Triple DES. Dữ liệu được mã hóa trong chế độ mã hóa CBC.
1.3.2.4. Dạng thơng tin mà TDE có thể mã hóa
TDE hoạt động tại mức I/O thông qua pool đệm. Do vậy, bất kỳ dữ liệu được ghi vào các tệp cơ sở dữ liệu (*.mdf) được mã hóa. Các Snapshot và các bản sao cũng được TDE hỗ trợ và chúng cũng được mã hóa trên đĩa. Tuy nhiên dữ liệu trong khi sử dụng khơng được mã hóa, bởi vì TDE khơng cung cấp việc bảo vệ mức bộ nhớ hoặc mức trên đường truyền. Nhật ký giao tác cũng được bảo vệ.
Đối với dữ liệu trong sử dụng, tất cả các trang được giải mã khi chúng được đọc và lưu trong các pool đệm và tồn tại dạng rõ trong bộ nhớ. Hệ điều hành có thể phân trang dữ liệu ra ngoài bộ nhớ giống như phần quản lý bộ nhớ. Trong quá trình này, dữ liệu được giải mã có thể được ghi ra đĩa. Windows và SQL Server có thể cấu hình để ngăn chặn việc này tuy nhiên
Nghiên cứu tìm hiểu một số dạng tấn công SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
hiệu năng sẽ bị giảm. Dữ liệu trong khi truyền không được bảo vệ bởi vì thơng tin thực sự đã được giải mã trước khi dữ liệu được truyền. SSL có thể được thiết lập để bảo vệ giao tiếp giữa server và clients.
Khi tệp trang cơ sở dữ liệu được ghi ra đĩa thì các phần header là khơng được mã hóa bởi vì thơng tin này là cần thiết để trang đó được tải lại. Phần header này gồm: mức tương thích của cơ sở dữ liệu, phiên bản cơ sở dữ liệu, trạng thái phản ánh,… Bất kỳ dữ liệu quan trọng (như DEK) được mã hóa trước khi được chèn vào header. Header bao gồm kiểm tra hỏng dữ liệu (CRC). Người dùng có thể có một checksum trên bản rõ và một checksum trên bản mã. Checksum này chỉ để phát hiện hỏng dữ liệu (kiểm tra xem dữ liệu có thể đọc được) và khơng tồn vẹn dữ liệu (kiểm tra xem dữ liệu có bị sửa đổi). Tất cả dữ liệu người dùng khác được lưu trong trang cơ sở dữ liệu là đều được mã hóa, bao gồm các phần dữ liệu chưa sử dụng (hoặc các phần dữ liệu đã bị xóa trước đó) để tránh làm rị rỉ thơng tin.
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
CHƯƠNG II: TÌM HIỂU VỀ MỘT SỐ KỸ THUẬT TẤN CÔNG SQL INJECTION
2.1. MỘT SỐ TẤN CÔNG CƠ SỞ DỮ LIỆU PHỔ BIẾN
Một số tấn cơng vào cơ sở dữ liệu thường thấy:
• Cấp phát quyền cơ sở dữ liệu quá mức cần thiết: Khi người dùng (hoặc ứng dụng) được gán các quyền cơ sở dữ liệu vượt quá các yêu cầu của chức năng cơng việc thì các quyền này có thể bị lạm dụng để thực hiện truy cập tới thơng tin bí mật. Ví dụ, cơng việc người quản lý ở trường đại học chỉ có u cầu xem thơng tin về các sinh viên. Nếu như người này được gán quyền quá mức cần thiết – đó là quyền cập nhật, thì họ có thể thay đổi điểm số. Giải pháp giải quyết vấn đề này là điều khiển truy cập mức truy vấn. Điều khiển truy cập mức truy vấn sẽ hạn chế tối thiểu các quyền khi thực hiện yêu cầu và dữ liệu.
• Lạm dụng quyền: Người dùng có thể lạm dụng các quyền truy cập hợp pháp cho các mục đích trái phép. Giải pháp giải quyết vấn đề này là các chính sách điều khiển truy cập không chỉ áp dụng cho dữ liệu nào có thể truy cập, mà cịn áp dụng cho cách thực truy cập dữ liệu dữ liệu đó.
• Leo thang quyền trái phép: Kẻ tấn cơng có thể sử dụng ưu thế của các lỗ hổng trong phần mềm quản trị cơ sở dữ liệu để chuyển đổi các quyền truy cập mức thấp thành các quyền truy cập mức cao. Giải pháp giải quyết vấn đề này là kết hợp giữa điều khiển truy cập mức truy vấn với các hệ thống ngăn chặn truy nhập (IPS).
• Các lỗ hổng trong các hệ điều hành: Kẻ tấn cơng có thể tận dụng các lỗ hổng trong hệ điều hành để truy cập và thay đổi dữ liệu trái phép. Ví dụ, sâu Blaster lấy ưu thế của các lỗ hổng trong Windows 2000 để tấn công lên các server mục tiêu.
• SQL Injection: Các tấn cơng SQL injection liên quan đến người dùng, là người đã đưa ra các lợi thế cho các lỗ hổng trong các ứng dụng Web và thủ tục lưu trữ, để gửi các câu truy vấn trái phép với các quyền đã
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
được nâng cao. Sử dụng SQL Injection, kẻ tấn cơng có thể đạt được việc truy cập không hạn chế tới tồn bộ cơ sở dữ liệu.
• Kiểm tra, giám sát yếu kém: Các cơng nghệ và chính sách kiểm tra (audit) cịn yếu trong việc mơ tả, ngăn cản, phát hiện, pháp lý và khôi phục. Hầu hết các giải pháp kiểm tra hệ quản trị cơ sở dữ liệu đểu thiếu tính chất cần thiết. Ví dụ các sản phẩm hiếm khi ghi lại nhật ký mà ứng dụng truy cập đến cơ sở dữ liệu, địa chỉ IP nguồn và các truy vấn lỗi.
• Tấn cơng từ chối dịch vụ: Được thực hiện bằng nhiều kỹ thuật như tràn bộ đệm, sửa đổi làm sai lệch dữ liệu, làm ngập lụt mạng. Tuy nhiên trong môi trường cơ sở dữ liệu, kỹ thuật làm tiêu thụ tài nguyên thường bị bỏ quên.
• Các lỗ hổng trong giao thức cơ sở dữ liệu: Điều này có thể cho phép truy cập dữ liệu trái phép. Ví dụ con sâu SQL Slammer nhận các ưu thế của lỗ hổng giao thức Microsoft SQL Server để thực hiện mã tấn công trên các server cơ sở dữ liệu. Các tấn cơng giao thức có thể được chống bằng cách phân tích và xác nhận các giao tiếp SQL để đảm bảo chúng là khơng khác thường.
• Cơ chế xác thực yếu: Các lược đồ xác thực yếu cho phép kẻ tấn công chiếm lấy được định danh của người dùng cơ sở dữ liệu.
• Tiết lộ các bản sao cơ sở dữ liệu: Gần đây các tấn công được mô tả liên quan đến lấy việc trộm các bằng từ và đĩa cứng chứa bản sao cơ sở dữ liệu. Do vậy tất cả các bản sao này cần phải được mã hóa. Trong thực tế, một số nhà chế tạo đã đề nghị trong tương lai các sản phẩm có thể khơng hỗ trợ việc tạo các bản sao mà khơng được mã hóa.
2.2. MỘT SỐ KỸ THUẬT TẤN CÔNG SQL INJECTION2.2.1. Khái niệm về tấn SQL injection: 2.2.1. Khái niệm về tấn SQL injection:
Một tấn công SQL injection (SQLIA - SQL Injection Attack) bao gồm việc chèn (insertion) hoặc “tiêm” (injection) một truy vấn SQL thông qua dữ liệu đầu vào từ client đến ứng dụng. Khi việc khai thác SQL injection thành cơng thì kẻ tấn cơng có thể đọc được dữ liệu nhạy cảm từ cơ sở dữ liệu, sửa
Nghiên cứu tìm hiểu một số dạng tấn công SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
đổi dữ liệu trong cơ sở dữ liệu (chèn, cập nhật, xóa), thực hiện các thao tác quản trị trên cơ sở dữ liệu (như tắt hệ quản trị cơ sở dữ liệu), khám phá nội dung của các tệp tin được lưu trong cơ sở dữ liệu, và trong một số trường hợp thực hiện các lệnh của hệ điều hành. Các tấn công SQLIA là một dạng của kiểu tấn cơng “tiêm”, trong đó các lệnh SQL được chèn vào dữ liệu đầu vào để thực hiện các lệnh SQL đã được chuẩn bị trước.
2.2.2. Các cơ chế thực hiện tiêm
Các câu lệnh SQL nguy hiểm có thể được đưa vào trong ứng dụng dễ bị tấn công bằng cách sử dụng nhiều cơ chế đầu vào khác nhau. Dưới đây trình bày các cơ chế phổ biến.
2.2.2.1. Kỹ thuật tiêm thông qua đầu vào người dùng
Trong trường hợp này, kẻ tấn công tiêm các lệnh SQL bằng cách cung cấp đầu vào đã bị thay đổi theo cách thích hợp. Tùy vào mơi trường triển khai, ứng dụng Web có thể đọc dữ liệu đầu vào. Trong hầu hết các SQLIA mà mục tiêu là các ứng dụng Web, dữ liệu đầu vào được lấy từ các đệ trình form mà được gửi tới ứng dụng Web thông qua các yêu cầu HTTP GET hoặc POST. Các ứng dụng Web có thể truy cập tới dữ liệu đầu vào này giống như cách truy cập tới các biến trong mơi trường đó.
2.2.2.2. Kỹ thuật tiêm thông qua các coockie
Các coockie là các tệp tin có chứa thơng tin trạng thái được ứng dụng Web tạo ra và được lưu trên máy client. Khi một máy client quay trở lại ứng dụng Web thì các cookies đó có thể được dùng để khơi phục lại thơng tin trạng thái của client. Bởi vì client đã kiểm sốt được nơi lưu trữ cookie, cho nên một client hiểm độc có thể can thiệp vào nội dung của cookie. Nếu như ứng dụng Web sử dụng nội dung các cookie này để xây dựng nên các truy vấn SQL, thì kẻ tấn cơng có thể dễ dàng thực hiện một tấn công bằng cách nhúng nó vào trong cookie.
2.2.2.3. Kỹ thuật tiêm thơng qua các biến môi trường
Các biến server là tập các biến lưu các header HTTP, header mạng và các biến môi trường. Ứng dụng Web sử dụng các biến server này theo một số cách, như thống kê số lần đăng nhập và xác định xu hướng. Nếu các biến này
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
đăng nhập tới cơ sở dữ liệu mà không được kiểm sốt, điều này có thể tạo các lỗ hổng cho tấn cơng SQL Injection. Bởi vì kẻ tấn cơng có thể giả mạo các giá trị đó, các giá trị này được đặt trong các header HTTP và header mạng. Chúng có thể khai thác điểm yếu này bằng cách đặt trực tiếp một SQLIA vào trong các header này. Khi truy vấn lưu lại biến server vào cơ sở dữ liệu thì ngay sau đó tấn cơng trong header bị giả mạo được kích hoạt.
2.2.2.4. Kỹ thuật tiêm bậc hai
Trong các kỹ thuật tiêm bậc hai, kẻ tấn công thêm dữ liệu đầu vào nguy hại tới hệ thông hoặc cơ sở dữ liệu, để khi đầu vào đó được sử dụng ở lần sau thì sẽ gián tiếp kích hoạt SQLIA. Mục tiêu của kiểu tấn công này khác so với kiểu tấn công tiêm thông thường (tiêm bậc nhất). Kỹ thuật tiêm bậc hai không gây ra tấn cơng đó khi dữ liệu đầu vào nguy hại đó tới được cơ sở dữ liệu lần đầu tiên. Thay vì đó kẻ tấn cơng biết được tri thức về vị trí của dữ liệu đầu vào sẽ được sử dụng tiếp theo và tấn công được thực hiện đồng thời trong quá trình người dùng làm việc. Dưới đây trình bày một ví dụ tấn cơng tiêm bậc hai. Trong ví dụ này, người dùng đăng ký trên website sử dụng một tên người dùng đã bị thay đổi, ví dụ “admin’ --”. Tại thời điểm người dùng thay đổi mật khẩu và toán tử liên quan đến việc kiểm tra xem người dùng có biết mật khẩu hiện tại và thay đổi mật khẩu nếu như việc kiểm tra này thành công. Để thực hiện được công việc này, ứng dụng Web có thể xây dựng câu truy vấn như sau:
queryString="UPDATE users SET password=’" + newPassword + "’ WHERE userName=’" + userName + "’ AND password=’" + oldPassword + "’"
newPassword và oldPassword là mật khẩu mới và mật khẩu cũ, và userName là tên của người dùng hiện tại. Giả sử newPassword và oldPassword là “newpwd” và “oldpwd”, thì truy vấn được gửi tới cơ sở
dữ liệu là:
UPDATE users SET password=’newpwd’
Nghiên cứu tìm hiểu một số dạng tấn cơng SQL Injection vào hệ quản trị CSDL Microsoft SQL Server
Do “--” là tốn tử chú thích SQL, mọi thứ sau nó sẽ bị cơ sở dữ liệu bỏ qua. Bởi vậy, kết quả của câu truy vấn là cơ sở dữ liệu thay đổi mật khẩu của người quản trị thành giá trị mà kẻ tấn công chỉ định.
Kỹ thuật tiêm bậc hai có thể là khó phát hiện và ngăn chặn bởi vì điểm tiêm là khác so với điểm mà tấn công thực sự xuất hiện. Người phát triển hồn tồn có thể tránh, kiểm tra kiểu, và lọc dữ liệu đầu vào và khẳng định