TẤN CÔNG ROOTKIT TRONG ORACLE
1.1.13. Cách thức tấn công của rootkit
Thay đổi view source bằng cách modify binary
Oracle lưu các thông tin về username, job, process trong các data dictionary view. Và người quản trị sẽ truy vấn các view này để có được thông tin về cơ sở dữ liệu mình quản lý, các process, các job đang hoạt động. Cụ thể, thông tin về user có trong sys.user$, dba_users, all_user,
Thông tin về Có trong các table, view
User sys.user$, dba_users,
all_users
Job dba_jobs, dba_jobs_running, sys.job$
Process v$session, gv_$process, flow_session, v_$process
Đầu tiên xem source của view trong v$fixed_view_definition như sau:
Select view_definition From v_$fixed_view_definition where view_name = ‘V$PWFILE_USERS’;
Ta được:
select USERNAME , SYSDBA , SYSOPER from GV$PWFILE_USERS where inst_id = USERENV ('Instance')
Nhưng vấn đề là view GV$PWFILE_USERS là fixed view (view cố định). Oracle user bao gồm cả Sysdba không thể thay đổi source code của nó. Attacker sẽ tìm cách nào đó thay đổi source code của view này để che giấu tài khoản sysdba Hacker của hắn:
Select view_definition from v$fixed_view_definition where view_name = ‘GV$PWFILE_USERS’;
Kết quả:
VIEW_DEFINITION
--- select inst_id,username,decode(sysdba,1,'TRUE','FALSE'),
decode(sysoper,1,'TRUE','FALSE') from x$kzsrt where valid=1 and username != 'INTERNAL'.
Attacker sẽ muốn thay đổi source code của gv$pwfile_users thành:
select inst_id,username,decode(sysdba,1,'TRUE','FALSE'),
decode(sysoper,1,'TRUE','FALSE') from x$kzsrt where username not in ('INTERNAL', ‘HACKER’)
Vì thế, attacker sẽ phải tác động tới phần binary để source của fixed view mới bị ảnh hưởng. Sử dụng công cụ như hexeditor search hoặc tương tự để tìm chuỗi ‘GV$PWFILE_USERS’.
Hinh 16:Truoc khi thay đôi binary
Hinh 17:Sau khi thay đổi binary.
Sau đó, copy binary đã edit vào file ban đầu.
Thay đổi đường dẫn thực thi
Đối với việc thay đổi đường dẫn thực thi, điều mà chúng ta quan tâm là cách thức DB Oracle phân giải tên các object được truy vấn như thế nào.
Trong rootkit OS, đường dẫn tới các lệnh *NIX như ps, who, top bị sẽ bị thay đổi. Trong database, một phiên bản bị trojan sẽ được gọi thay vì phiên bản ban đầu. Hướng tiếp cận này có lợi thế đối với attacker, việc kiểm tra mã checksum cũng không phát hiện được thay đổi này. Ví dụ, xem xét truy vấn:
Select user_name from DBA_USERS.
Oracle sẽ phân giải tên object user_name này như thế nào? Đầu tiên Oracle kiểm tra xem liệu có một local object(table hay view) là DBA_USERS. Nếu có, object này được dùng cho query. Nếu không, Oracle tiếp tục tìm một private synonym có tên như vậy. Nếu không có nó sẽ kiểm tra một public synonym. Dựa trên cấu trúc của đường dẫn thực thi của Oracle, sẽ có một số cách có thể cho việc thi hành một rootkit như sau:
Hinh 18: Đường dẫn thực thi trong Oracle - Tạo một local object mới với tên giống với trong user schema.
- Tạo một object mới tham chiếu tới object ban đầu( view hay table) hoặc một object mới chứa bản sao của data trong object ban đầu. Bảng DBA_USERS nên được cập nhật với một trigger trên SYS.USER$
- Tạo một private synonym và một local object mới.
- Chỉnh sửa một public synonym và tạo một local object mới.
Hinh 19: Trước khi thay đổi đường dẫn thực thi
Tạo view mới system.all_users2:
Hinh 20: Tạo view mới
Sau đó, tạo một private synonym system.all_users cho system.all_users2:
Create synonym system.all_users for system.all_users2;
Khi đó, truy xuất tới all_users, thông tin sẽ xuất phát từ view mới được tạo trên.
Hinh 1 : Truy xuất sau khi thay đổi đường dẫn
Điểm bất lợi của ba phương pháp đầu là chỉ schema của người sở hữu bị ảnh hưởng bởi các thay đổi này. Attacker phải tạo các object khác nhau cho các tài khoản admin khác nhau. Hầu hết attacker sẽ dùng cách thứ 4 vì view nguyên bản không bị sửa đổi và nó áp dụng với mọi tài khoản ngoại trừ SYS.
Thay đổi các package PL/SQL
Các source code của package dễ bị chỉnh sửa. Hầu hết các package do Oracle tạo ra đều được wrap và bảo vệ không bị chỉnh sửa. Đây chính là lỗ hổng mà rootkit sử dụng để hoạt động.
Thông thường, sau khi tạo một thủ tục lưu trữ, có thể truy nhập mã nguồn thông qua bảng SOURCE, như sau:
SQL> SELECT text FROM USER_SOURCE
SQL> WHERE name = 'WRAPTEST' order by line;
Kết quả:
PROCEDURE wraptest IS
TYPE emp_tab IS TABLE OF emp%ROWTYPE INDEX BY PLS_INTEGER;
all_emps emp_tab;
BEGIN
SELECT * BULK COLLECT INTO all_emps FROM emp;
FOR i IN 1..10 LOOP
DBMS_OUTPUT.PUT_LINE('Emp Id: ' || all_emps(i).empno);
END LOOP;
END;
Làm thế nào để tránh điều này? Nhiều lập trình viên Oracle không load các procedure này vào database mà đặt nó vào một file SQL trên server và thực hiện từ xa. Bất kì ai có thể truy nhập tới server sẽ đọc được file này, nhưng bằng cách này bạn cũng đã phần nào hạn chế được truy nhập theo ý mình. Còn trong trường hợp, nếu code để ở database, nó nên được wrap thành một hoặc một phần của package.
Wrapping là một phương pháp thay đổi mã PL/SQL dạng rõ thành các kí tự mà chỉ Oracle đọc được. Như vậy, nó vẫn được biên dịch và thực hiện như bình thường, mà vẫn được bảo vệ an toàn. Nhưng hacker có thể dùng
các công cụ wrap và unwrap để sửa đổi lại mã các procedure, package với các phiên bản Oracle không sử dụng checksum.
PL/SQL Native compilation
Khi tạo một chương trình PL/SQL trong oracle 8i, oracle lưu cả source code và byte code đã compile vào data dictionary. Phân tích, kiểm duyệt và tạo byte code là những gì diễn ra khi tạo object. Khi thực thi một chương trình, PL/SQL interpreter trong database server chỉ đọc các byte code và thực hiện những vận hành nhất định. Điều này tránh phải phân tích, kiểm tra cú pháp và các bước khác ở thời điểm runtime. Sang oracle 9i, có thêm sự lựa chọn biên dịch PL/SQL native thay vì tạo các byte code cho interpreter. Bắt đầu từ Oracle 9i chúng ta có thể biên dịch các procedure PL/SQL sang mã máy trên database server. Oracle thông báo rằng sử dụng procedure được biên dịch sang ngôn ngữ nguyên thủy sẽ giúp giảm thời gian làm việc với PL/SQL tới 10 lần. Khi tạo một chương trình PL/SQL có native compilation, oracle sẽ lưu source code trong data dictionary và thực hiện việc phân tích và kiểm duyệt như bình thường khi tạo object. Nếu code hợp lệ, oracle sẽ tạo một file nguồn C và gọi trình biên dịch và linker C để tạo file thư viện chia sẻ cho chương trình PL/SQL đó. Nghĩa là file .dll/ .lib sẽ được thực thi thay vì package PL/SQL ban đầu. Trong khi đó, trước các phiên bản 10g, Oracle không quản lý các file trong hệ thống file của OS. Kể từ 10g, các file .dll/ .lib được lưu trong database. Nhưng như vậy cũng đã đủ để thực hiện một số thao tác nhất định. Khá dễ dàng sử dụng PL/SQL native để thực thi các lệnh OS thông qua lệnh ‘alter system’.
Ví dụ:
Alter system set plsql_native_make_utility=’calc.exe’;
Alter system set
plsql_native_make_file_name=’c:\temp\mymakefile.mk’;
Alter system set plsql_native_library_dir=’c:\temp\plsql_libs’;
Sau mỗi lần biên dịch mã PL/SQL, Oracle bắt đầu trình biên dịch PL/SQL, tức là gọi tới tiện ích calculator của Windows.
Ví dụ, chúng ta có thể cài đặt một backdoor trong package myprocedure.
Biên dịch sang mã máy. Được các file .c và .dll.
Hinh 22:Sử dụng PL/SQL native
Sau đó, gỡ backdoor ra khỏi package, biên dịch lại lần nữa. Thay thế các file mới biên dịch bằng phiên bản backdoor trước đó. Package trong database không bị backdoor nhưng mỗi lần gọi tới package, backdoor của hacker lại đượcchạy.
Hinh 23: Sử dụng PL/SQL native