Ẩn tài khoản truy nhập
User Oracle được lưu trong table SYS.USER$ cùng với database role. User có flag TYPE#=1 và role có flag TYPE#=0. Để việc truy nhập dễ dàng hơn, và đảm bảo tính tương thích với các phiên bản trước, Oracle đưa ra 2 view là DBA_USERS và ALL_USERS thông qua public synonym. Hầu hết các DBA và các công cụ sử dụng các view này để truy nhập table SYS.USER$. Vì vậy để ẩn đi các user muốn che giấu cần sửa các view source:
Hinh 10 : Trước khi ẩn user Hacker
Mọi thay đổi trên view thuộc về SYS yêu cầu quyền SYSDBA( Cần có một mục về các tài khoản và quyền hạn trên Oracle). Sau đó truy vấn trở lại view trên sẽ không thấy xuất hiện tài khoản đó:
Hinh 11 : Sau khi ẩn user Hacker
Thông thường attacker sẽ chọn các username khó phát hiện(ví dụ MTSYS) và một câu điều kiện không dễ nhận ra( ví dụ AND U.USER#<> 17, trong đó 17 là chỉ số của user mới được tạo). Vì thế Developer hoặc các DBA không nên dựa vào view, mà nên truy nhập các table căn bản như SYS.USER$.
Ẩn Process
Oracle process được chia làm 3 loại:
User process: Bắt đầu khi database user yêu cầu kết nối tới Oracle server
Server process: Xử lý các yêu cầu từ user process kết nối tới instance. Background process: Là các tiến trình tương tác lẫn nhau và với hệ điều hành để quản lý bộ nhớ, quản lý các tín hiệu nhập xuất để ghi dữ liệu ra đĩa, và một số nhiệm vụ khác. Nó được bắt đầu khi Oracle instance hoạt động.
Hinh 12:v$session trước khi ẩn session
Hinh 13:v$session sau khi ẩn session
Các tiến trình được lưu trong view v$session nằm ở schema Sys. Ngoài ra thông tin về mỗi session còn xuất hiện trong gv_$sessions, flow_sessions, v_$process.
Ẩn Database Jobs
Job là những tác vụ cần được thực hiện tại một thời điểm nào đó và có thể lặp lại. Lập lịch chạy job giúp tự động hóa công việc quản trị. Ví dụ lập lich update, import, export dữ liệu. Thông tin về tất cả các job có trong dba_jobs, sys.job$, dba_jobs_running.
Giả sử hacker cần tạo một job để chạy tại một thời điểm nào đó ví dụ export dữ liệu, thì cần là phải ẩn các job này. Để job này không hiển thị khi truy vấn dba_jobs thì cần phải giấu đi priv_user: quyền của user mà job
được sử dụng. Do chỉ có job do tài khoản hacker tạo sẽ chạy bằng quyền của hacker.
Dba_jobs trước và sau khi ẩn job của attacker.
Hinh 14:dba_jobs trước khi ẩn job
Hinh 15:dba_jobs sau khi ẩn job
Xóa Oracle listener log
Trong quá trình ghi log, các thông tin được log trong listener.log của TNS-listener(nếu kích hoạt logging). Gỡ bỏ các dấu vết có trong các file này là điều cần thiết với attacker. Oracle đưa ra nhiều cách để thực hiện điều này. Cách dễ nhất là dùng package utl_file. Package này cho phép đọc (UTL_FILE.GET_LINE), viết (UTL_FILE.PUT_LINE) hay xóa (UTL_FILE.REMOVE) file. Log file không bị cấm(lock) bởi TNS listener, nhờ đó có thể thay đổi nội dung ở tại thời điểm đang hoạt động (runtime).
Xóa Oracle SGA
Các dấu vết của một attack cũng lưu trong bộ nhớ của database(SGA, System Global Area). Mọi câu lệnh SQL đã thực thi bởi mỗi user cũng có trong view V_$SQLAREA. Để gỡ các thông tin này từ SGA, xóa shared pool bằng lệnh sau:
Alter system flush shared_pool;
Nhớ rằng xóa share pool sẽ ảnh hưởng tới hiệu suất của database, và user có thể sẽ than phiền về tốc độ truy nhập.
Xóa Oracle Redo-Log
Mọi transaction tạo thay đổi lên database được lưu trong Redo-Log file và cũng lưu trong archive log, nếu database chạy ở chế độ archive log mode. Attacker cũng sẽ phải xóa các dấu vết này. Đầu tiên chạy lệnh để database switch một redo-log:
Alter system switch logfile;
Sau khi cài đặt rootkit, rootkit cần switch các redo log file trong tất cả redo log group để nội dung trong đó bị thay thế. Nếu database có thiết lập chế độ archive log, cần phải xóa tất cả archive file gần nhất bằng package utl_file.fremove.