Автор Тема: LKM rootkit  (Прочетена 4201 пъти)

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
LKM rootkit
« -: Nov 10, 2008, 23:18 »
Обхванала ме е една нова краста - пиша си един прост kernel rootkit, просто за да видя дали ще мога да се справя и защото ми е интересно (както винаги като ми дойде такава краста откривам разни забавни нови неща).

Методът, който ползвам е много прост и изтъркан - hijack-вам sys_call_table[]. Понеже таблицата в 2.6 не се експорт-ва съм си реализирал един procfs интерфейс, чрез който подавам от userspace-a адреса на sys_call_table[] (който вземам от System.map). Сега това е доста малоумно като цяло, знам че има доста по-advanced методи, като например тези дето си играят с debug регистрите, знам също и че зависи от System.map (това не е особен проблем, мога да го накарам да зависи и от /proc/kallsyms и да сканира област от паметта, но това не е толкова важно).

Засега успях вече да реализирам криене на файлове (това е елементарно, пипам sys_getdents() и където видя въпросният файл просто го подменям с "..\0" доста просто и ефективно).

Реализирах и криене на процеси (също не е голяма философия). В случаят правя един глупав номер - прихващам sys_chdir() и ако директорията е един определен стринг, слагам на current (тоя отдето е влезнато в kernelmode) task_struct-а полето pid=0. Убийствено ефективно, процесът престава да съществува запред procfs и никой не може да го види. Единственият проблем е ако процесът някъде викне exit() което краш-ва ядрото. За целта прихванах и sys_exit()/sys_exit_group() така че ако current task_struct->pid ==0, да го смени на current task_struct->tgid и чак тогава да викне оригиналният sys_exit(). Стана си стабилно и работи много добре. Просто трябва като си викнете bash shell-a да напишете "cd secretstring" и шела престава да съществува.

Реализирах и ескалиране на привилегии - по елементарен начин, много подобно на горния пример - на current task_struct->uid се дава стойност 0. При което процесът започва да работи с root привилегии, което е доста забавно :)

Сега остава да почна да крия сокети, за което имам идея как да стане - ще трябва обаче да прихвана sys_read() най-вероятно.

Другото което е - да скрия модула от списъка със заредени такива - не съм убеден, че ще стане, но доколкото знам всички заредени модули се пазят в някакъв свързан списък - просто ще разкарам моят оттам ако е възможно. Това още не съм го проучил, но не мисля, че ще е проблем. Ако ли не, ще видя дали не мога да направя нещо по въпроса с четенето от /proc/modules.

Сега остава най-забавното, за което нямам много идея как да стане - да си осигурим remote достъп. Разбира се мога да bind-на един сокет с nc, той да вика шел когато се вържеш (nc -l port -c /bin/bash) и да ги скрия, ама това не е много умно. Първо защото ще има слухтящ сокет, дори да го скрия от procfs (съответно netstat), едно сканиране на машината с nmap ще го покаже и ще почнат подозрения.

За целта мисля да пробвам с нещо, дето се занимавах преди време - netfilter hooks. Ще сет-на един такъв, който дроп-ва пакетите на този порт освен ако не са от определен source адрес. Ще е малко грубо, но ще свърши работа.

Обаче не знам...само това ли трябва да се очаква от един rootkit?

Гледах значи 1-2 писани неща...там те крият когато някой интерфейс влезе в promiscuous режим (това нямам идея как да го направя). Могат да логват нещата минали през tty-та, което ми се вижда леко безсмислено.

И въпреки това, каква още функционалност би следвало да има (освен криене на процеси/сокети/файлове)?

Другото което ми е много интересно е някакъв начин това да може да се зарежда автоматично при reboot (достатъчно скрито - като редактираш инитскриптове това обикновено се забелязва). Може би може да се измисли някаква схема с инитскриптовете където модификацията се "скрива" от администратора, но това ми се вижда ужасно сложна работа за реализация в kernelmode. Дали няма някакъв по-лесен начин?

Също така ми е интересно какво още би трябвало да се скрие? Аз мислех по въпроса че ще е добре да се предпазя от възможността скрит процес да пише неща в syslog, би било голяма простотия. Също така хахорската намеса просто лъщи като разгледаш /proc/kallsyms, поради което и там ще трябва да направя нещо по въпроса. Но честно казано идеите ми са дотам.

Та ми е интересно да чуя вие какво мислите? Примерно ако се усъмните, че някой ви е хахорнал машинката, какво бихте проверили?

А, да, срещу rkhunter още не съм правил тестове, рано е още :)
Активен

"Knowledge is power" - France is Bacon

ANTIADMIN

  • Участник
  • *****
  • Публикации: 660
  • Distribution: Windows XP Pro latest updates
  • ANTIADMIN
    • Профил
Re: LKM rootkit
« Отговор #1 -: Nov 11, 2008, 00:05 »
цитат->Та ми е интересно да чуя вие какво мислите? Примерно ако се усъмните, че някой ви е хахорнал машинката, какво бихте проверили?
sniff, sniff ;D паля tripwire и веднага лъсваш, имаше още няква глупост ossec май се казваше ;D
А какво те притеснява рибута?
Според мен ще е грешка да е универсален, т.е. само да се крие и да прави нещо, да краде, да те пуска вътре, но не всичко наведнъж.
Ма аз съм с БСД, не вървиш с тоя руткит ;D
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #2 -: Nov 11, 2008, 00:10 »
Ами tripwire прави MD5 суми на всички файлове от файловите системи, поради което ще намери дедовия си :) Красотата на kernel-базираните rootkits е че не се модифицират binaries или библиотеки, вместо това зареждаш модул за ядрото, който прихваща системни извиквания и прави каквото си знае с тях :) Което е по-бруталното, прихващайки системни извиквания за четене на файлове на теория би могъл да накараш програми като tripwire да вярват, че модифициран файл няма никаква промяна. Но това си е чисто на теория. Специално в случаят tripwire не ми пречи - по-скоро някакви гадости, които имат навика да проверяват интегритета на sys_call_table[] ще го открият веднага, защото адресите на някои функции са променени.
Активен

"Knowledge is power" - France is Bacon

ANTIADMIN

  • Участник
  • *****
  • Публикации: 660
  • Distribution: Windows XP Pro latest updates
  • ANTIADMIN
    • Профил
Re: LKM rootkit
« Отговор #3 -: Nov 11, 2008, 00:16 »
IntoXonia - LKM rootkit for Linux Kernel 2.6.x
Код:

(*) скрытие файлов/каталогов (*) скрытие процессов (*) имитация полного удаления файлов (*) перенаправление обращения к файлам (*) перенаправление входа в директории (*) запрет на обращение к файлам (*) запрет на вход в каталог (*) добавление фиктивной строки в файл (*) скрытие строки из файла (*) замена строк в файле при чтении (*) защита файла от удаления (*) сохранение файла при удалении (*) защита процессов (*) создание алиасов для команд (*) перенаправление запуска бинарников (*) запрет на запуск программ (*) запись всех нажатых клавиш (кейлоггер) (*) сниффер POP3/FTP паролей (*) сохранение настроек в файл (*) загрузка настроек из файла (*) получение прав root (*) смена uid/gid процесса (*) защищенное удаление файлов (*) настройка с помощью фиктивного бинарника (*) защита всех настроек паролем

http://damagelab.org/index.php?showtopic=5633&hl=intoxonia
Ето например тоя какво прави ;D Ти да не четеш в оня сайт от США на издателите на книгата за уиндоус кърнъла?
Като си готов, ще си пожелаем и други функции ;D
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #4 -: Nov 11, 2008, 00:30 »
Да живее google translate :D

(*) To hide files / directories (*) to hide processes

това е готово

(*) imitation of a complete removal of the files (*)

това е идейно :)

redirection of the files (*) redirecting the entrance to the directory

не виждам смисъл, ама ОК - и sys_open() можем да бутнем.

ban on entry in the directory ( *)

не ми допада като идея.

Adding fictitious line in the file (*) to hide file lines

Идейно. Върху това може да се поработи.

(*) replacement strings in the file while reading

Дефакто същото като горното.

(*) file protection from removal

не, тъпо е - само буди подозрения.

(*) save the file when you remove

И това е интересно

 (*) Creating an alias for a command ( *) Redirect start binaries (*) ban on launching programs (*) record all keystrokes (keyloggers) (*) sniffer POP3/FTP passwords

Не ми допада като идея.

(*) save settings file (*) to retrieve configuration file

?!?

(*) rights root

Направено е.

(*) Change uid / gid process

Няма нужда.

(*) securely delete files

Интересно, но няма особен смисъл - мога да си ги занулявам и без да пиша код по въпроса.

(*) setting using fictitious binaries

Това е забавната странична черта на това че ползвам procfs. При мен може и с echo > procfs.

(*) protection of all settings, password

Ммм не.

Russian
 
»
English
 
Translate
      

Мдам.
Активен

"Knowledge is power" - France is Bacon

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #5 -: Nov 11, 2008, 23:56 »
Хм много грубо.

Когато един скрит процес форк-не нов такъв, той има "нормален" PID (не 0). Следователно всякакви форкнати процеси се виждат.

Мислех известно време как да реша този проблем, първо реших, че може да прихвана sys_execve(), но това се оказа ОГРОМНА грешка, костваща много крашвания. Прихващането на точно тая функция е едно безумие.

Мислех какво да направя, strace-вах известно време bash шела и установих една забавна зависимост - когато се създаде нов процес, libc веднага след зареждането на ELF binary-то увеличава малко големината на heap-а чрез brk(), това за да се грижи за малки заделяния на памет предполагам без да се налага да се влиза в kernelmode.

Та воала - прихванах sys_brk() и всеки новосъздаден процес бива скрит. Дотук много добре...


...ооообаче както горе бях споменал, унищожаването на процес, който има pid==0 води до kernel panic и един тъп надпис "attempting to kill an idle task". Сега аз хубаво прихващам sys_exit() но понякога процесите отиват в нищото и поради други причини, примерно щото са получили сигнал някакъв, знам ли, факт е че форк-на ли скрит процес и ако го убия с ctrl-c дефакто убивам машината :)

Рових се пак из сорса на ядрото и установих че това се вика от do_exit(). Рових се из гугъл и там на едно място даваха идея как да се оправят нещата. За жалост архитектурно-зависимо. Те предлагат просто този малък регион от паметта, заета от do_exit() който прави CALL panic да се презапише с NOP (0x90).

Което звучи не особено сложно, обаче всъшност хич не е така.

За мое добро, на 2 машини гледах, тези две функции и на двете се намират една след друга в паметта, примерно така:

ffffffff802376f7 T do_exit
ffffffff80237dab T do_group_exit

Така че аз знам каква част от паметта заема do_exit() и къде се намира. Остава в рамките на този регион да потърся за стойност, отговаряща на адреса на panic (тук примерно според System.map:

ffffffff8023482a T panic
)

и доволно добре да презапиша с 0x90 стойността, както и за всеки случай малко преди и след нея. Разбира се това ще стане успешно след бая експерименти.


А, да, криенето на модула се оказа доста лесно - разкарах го от въпросния свързан списък и модулът вече не се води зареден. Тъпото е че няма rmmod-ване веднъж заредиш ли го, поне не и докато не ребуут-неш машината.

И да, голямо приключение се оказва засега. Скоро ще науча наизуст sched.h и syscalls.h ако продължавам в тоя дух :)
Активен

"Knowledge is power" - France is Bacon

tarator

  • Участник
  • *****
  • Публикации: 849
    • Профил
Re: LKM rootkit
« Отговор #6 -: Nov 12, 2008, 00:33 »
Хмм... Не, няма да казвам нищо. Малоумните начинания не трябва да се поощряват :)
Активен

A gentleman is one who is never rude unintentionally. - Noel Coward

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #7 -: Nov 12, 2008, 00:37 »
Мда, докато някой не си строши достатъчно главата с тях :) Съгласен съм, обаче ми е забавно и няма да мирясам, докато не го докарам до работещо състояние :)
Активен

"Knowledge is power" - France is Bacon

tarator

  • Участник
  • *****
  • Публикации: 849
    • Профил
Re: LKM rootkit
« Отговор #8 -: Nov 12, 2008, 02:04 »
alright. Защо се опитваш да прехванеш sys_exec вместо sys_fork (sys_clone и т.н.)? exec не създава нов процес :Р
Активен

A gentleman is one who is never rude unintentionally. - Noel Coward

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #9 -: Nov 12, 2008, 08:46 »
Не, това наистина го реших вече :)

Защо brk(), а не clone() или fork() - ами малко по-лесно ми излезе :)

Апропо, викането на clone() с CLONE_PID от скрит процес автоматично пръква скрито дете. Забавно :)
Активен

"Knowledge is power" - France is Bacon

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #10 -: Nov 12, 2008, 10:20 »
Хммм...значи в един форум свързан с kernel програмиране има една тема за intercept-ване на sys_call_table[], където един пич обяснява, че от 2.6.21 нататък това е невъзможно. Когато му казах че е възможно, защото съм го правил вкъщи с 2.6.26 ядро, той вика следното:

Цитат
I don't know whether or not this has been changed in Linux 2.6.26-1-amd64, but in Linux 2.6.21.5 as taken from http://kernel.org puts the sys_call_table in a read-only section of the memory. This means that you still cannot fiddle with it.

Could you please confirm whether or not this has been changed in Linux 2.6.26-1-amd64 by looking at file `arch/i386/kernel/entry.S' and see whether the following is listed there:

.section .rodata,"a"
#include "syscall_table.S"

If it still says .rodata,"a" and you can successfully fiddle with the sys_call_table that results from the compilation of the source code, I think it means that the read-only section is not enforced in the kernel realm unless you activate the feature of protecting read-only data structure through the kernel hacking menu of `menuconfig'.

Аз тествам на 2.6.16 (където нямам проблеми) и на 2.6.26 (64-битов) - където пак нямам проблеми.

От друга страна, на 2.6.26 има два файла:

arch/x86/kernel/entry_32.S:

Цитат
.section .rodata,"a"
#include "syscall_table_32.S"

и arch/x86/kernel/entry_64.S, който не съдържа такова нещо.

Мене ми е интересно дали въобще ядрото признава read-only секции от паметта или не.


Обаче нямам i386 машина с ядро над 2.6.21 на която да мога да тествам.

Значи направих една много орязана версия на rootkit-а , която дефакто няма rootkit функционалност - не може да крие процеси и файлове, единственото което прави е да patch-не sys_call_table[] и да прихване sys_chdir(). Когато се опитате да влезете в една определена директория (която вие си определяте) ще ви даде грешка и ще излезе едно съобщение в dmesg (TEST SUCCEEDED!).

Може ли някой с 32-битов линукс и с ядро > 2.6.21 да го изтества това нещо? Най-лошото, което може да се случи е да крашне системата и да се наложи рестарт, няма други рискове :)

http://www.maxishare.net/en/file/8948/rktest-tgz.html

Значи в архива има един шел-скрипт (inittest.sh) който трябва да се изпълни, това е почти всичко. Той компилира, зарежда модула, подава му през procfs каквото трябва. Единствено ще трябва да си въведете някакъв secretstring, след края на скрипта да напишете cd secretstring и да видите дали ще се изпише нещо в dmesg. После да разкарате модула с rmmod rktest

Може ли някой да го пробва, моля?
Активен

"Knowledge is power" - France is Bacon

manul

  • Участник
  • *****
  • Публикации: 16
    • Профил
Re: LKM rootkit
« Отговор #11 -: Nov 12, 2008, 14:28 »
Цитат
root@wattman:/home/manul/Desktop# cd rktest/
root@wattman:/home/manul/Desktop/rktest# uname -a
Linux wattman 2.6.27-4.slh.5-sidux-686 #1 SMP PREEMPT Mon Nov 3 20:16:18 UTC 2008 i686 GNU/Linux
root@wattman:/home/manul/Desktop/rktest# ls
total 36
drwxr-xr-x  2 manul manul 4096 2008-11-12 07:10 .
drwxr-xr-x 11 manul manul 4096 2008-11-12 07:08 ..
-rwxr-xr-x  1 manul manul  931 2008-11-12 03:03 inittest.sh
-rw-r--r--  1 manul manul 1468 2008-11-12 07:10 make.err
-rw-r--r--  1 manul manul  270 2008-11-12 02:57 Makefile
-rw-r--r--  1 manul manul    0 2008-11-12 07:10 Module.markers
-rw-r--r--  1 manul manul   44 2008-11-12 07:10 modules.order
-rw-r--r--  1 manul manul    0 2008-11-12 07:10 Module.symvers
-rw-r--r--  1 manul manul 2353 2008-11-12 03:00 rktest.c
-rw-r--r--  1 manul manul 7912 2008-11-12 07:10 rktest.ko
root@wattman:/home/manul/Desktop/rktest# ./inittest.sh
Compile successful
Found system.map - /boot/System.map-2.6.27-4.slh.5-sidux-686
Found sys_call_table address - 0xc035c860

Patching sct address...

Please enter your magic string...
magicstring


Good, now type cd magicstring
Observe dmesg..
And don't forget to rmmod rktest after that :)

root@wattman:/home/manul/Desktop/rktest# cd magicstring
manul@wattman:~$ tail /var/log/messages
tail: cannot open `/var/log/messages' for reading: Permission denied
manul@wattman:~$ sux
Password:
Segmentation fault
root@wattman:/home/manul# tail /var/log/messages
Nov 12 07:15:56 wattman kernel: Bluetooth: HCI device and connection manager initialized
Nov 12 07:15:56 wattman kernel: Bluetooth: HCI socket layer initialized
Nov 12 07:15:56 wattman kernel: Bluetooth: L2CAP ver 2.11
Nov 12 07:15:56 wattman kernel: Bluetooth: L2CAP socket layer initialized
Nov 12 07:15:56 wattman kernel: Bluetooth: RFCOMM socket layer initialized
Nov 12 07:15:56 wattman kernel: Bluetooth: RFCOMM TTY layer initialized
Nov 12 07:15:56 wattman kernel: Bluetooth: RFCOMM ver 1.10
Nov 12 07:15:58 wattman kernel: agpgart-intel 0000:00:00.0: AGP 3.0 bridge
Nov 12 07:15:58 wattman kernel: agpgart-intel 0000:00:00.0: putting AGP V3 device into 8x mode
Nov 12 07:15:58 wattman kernel: nvidia 0000:01:00.0: putting AGP V3 device into 8x mode
root@wattman:/home/manul# dmesg
.............
.............
Bluetooth: RFCOMM TTY layer initialized
Bluetooth: RFCOMM ver 1.10
agpgart-intel 0000:00:00.0: AGP 3.0 bridge
agpgart-intel 0000:00:00.0: putting AGP V3 device into 8x mode
nvidia 0000:01:00.0: putting AGP V3 device into 8x mode
eth0: no IPv6 routers present
BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<f8f1f15c>] :rktest:hacked_chdir+0x2c/0x60
*pde = 00000000
Oops: 0000 [#1] PREEMPT SMP
Modules linked in: rktest rfcomm l2cap bluetooth af_packet ipv6 fuse dm_crypt crypto_blkcipher vboxdrv w83627hf hwmon_vid sermouse xtkbd nvidia(P) serio_raw snd_intel8x0 rtc_cmos rtc_core rtc_lib snd_ac97_codec psmouse ac97_bus evdev pcspkr snd_pcm snd_seq snd_timer snd_seq_device snd rng_core i2c_i801 soundcore snd_page_alloc i2c_core iTCO_wdt iTCO_vendor_support parport_pc parport button shpchp pci_hotplug intel_agp ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod sd_mod pata_acpi usb_storage ata_piix ata_generic floppy libata skge scsi_mod dock ehci_hcd uhci_hcd usbcore thermal processor fan

Pid: 3012, comm: bash Tainted: P   M      (2.6.27-4.slh.5-sidux-686 #1)
EIP: 0060:[<f8f1f15c>] EFLAGS: 00210246 CPU: 0
EIP is at hacked_chdir+0x2c/0x60 [rktest]
EAX: 0000000b EBX: 0854c188 ECX: 0000000b EDX: 000000d8
ESI: 0000000c EDI: f8cee000 EBP: 0000000c ESP: f532ffa0
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process bash (pid: 3012, ti=f532e000 task=f513f9c0 task.ti=f532e000)
Stack: 00000000 0854c188 0854c188 00000000 f532e000 c0103eef 0854c188 00676e69
       00000001 0854c188 00000000 bfb82e28 0000000c 0000007b 0000007b c0100000
       0000000c b7f67424 00000073 00200246 bfb82dec 0000007b 00000000 000000ff
Call Trace:
 [<c0103eef>] sysenter_do_call+0x12/0x2f
 =======================
Code: ec 14 89 5c 24 04 89 74 24 08 89 7c 24 0c 89 6c 24 10 fc 89 c5 a1 0c 07 f2 f8 89 ee e8 ee 9d 31 c7 8b 3d 0c 07 f2 f8 89 c1 39 c0 <f3> a6 74 1c 89 e8 ff 15 08 07 f2 f8 8b 5c 24 04 8b 74 24 08 8b
EIP: [<f8f1f15c>] hacked_chdir+0x2c/0x60 [rktest] SS:ESP 0068:f532ffa0
---[ end trace f1c5c895266f37ad ]---
BUG: unable to handle kernel NULL pointer dereference at 0000000c
IP: [<f8f1f15c>] :rktest:hacked_chdir+0x2c/0x60
*pde = 00000000
Oops: 0000 [#2] PREEMPT SMP
Modules linked in: rktest rfcomm l2cap bluetooth af_packet ipv6 fuse dm_crypt crypto_blkcipher vboxdrv w83627hf hwmon_vid sermouse xtkbd nvidia(P) serio_raw snd_intel8x0 rtc_cmos rtc_core rtc_lib snd_ac97_codec psmouse ac97_bus evdev pcspkr snd_pcm snd_seq snd_timer snd_seq_device snd rng_core i2c_i801 soundcore snd_page_alloc i2c_core iTCO_wdt iTCO_vendor_support parport_pc parport button shpchp pci_hotplug intel_agp ext3 jbd mbcache dm_mirror dm_log dm_snapshot dm_mod sd_mod pata_acpi usb_storage ata_piix ata_generic floppy libata skge scsi_mod dock ehci_hcd uhci_hcd usbcore thermal processor fan

Pid: 3262, comm: lesspipe Tainted: P   M  D   (2.6.27-4.slh.5-sidux-686 #1)
EIP: 0060:[<f8f1f15c>] EFLAGS: 00210246 CPU: 1
EIP is at hacked_chdir+0x2c/0x60 [rktest]
EAX: 0000000b EBX: 09822d2c ECX: 0000000b EDX: 000000d8
ESI: 0000000c EDI: f8cee000 EBP: 0000000c ESP: f5379fa0
 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068
Process lesspipe (pid: 3262, ti=f5378000 task=f513e520 task.ti=f5378000)
Stack: 00000000 09822d2c 09822d2c 09822cf4 f5378000 c0103eef 09822d2c 00000000
       09822d34 09822d2c 09822cf4 bfda0658 0000000c 0000007b 0000007b c0350000
       0000000c b7f85424 00000073 00200246 bfda05bc 0000007b 00000000 00000000
Call Trace:
 [<c0103eef>] sysenter_do_call+0x12/0x2f
 [<c0350000>] serial8250_remove+0x10/0x42
 =======================
Code: ec 14 89 5c 24 04 89 74 24 08 89 7c 24 0c 89 6c 24 10 fc 89 c5 a1 0c 07 f2 f8 89 ee e8 ee 9d 31 c7 8b 3d 0c 07 f2 f8 89 c1 39 c0 <f3> a6 74 1c 89 e8 ff 15 08 07 f2 f8 8b 5c 24 04 8b 74 24 08 8b
EIP: [<f8f1f15c>] hacked_chdir+0x2c/0x60 [rktest] SS:ESP 0068:f5379fa0
---[ end trace f1c5c895266f37ad ]---
root@wattman:/home/manul#
root@wattman:/home/manul#
root@wattman:/home/manul# rmmod rktest
root@wattman:/home/manul#
root@wattman:/home/manul#
root@wattman:/home/manul#

При cd magicstring-a изби от рут в обикновен юзер... после при връщане в рут Segmentation fault.
Ядро 2.6.27
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #12 -: Nov 12, 2008, 15:21 »
Хм, да, утрепал ти е root-ския шел.

В hacked_chdir() най-вероятното място където съм бъркал неща указани от NULL pointer е онази memcpy() функция, но обяснение за случилото се нямам. Срам, не срам, ще те помоля да пейстнеш make.err, може оттам да излезе някакво обяснение. Това е странно поведение и е моя грешката че ме мързи да проверявам за NULL стойности указателите, преди да ги ползвам.
Активен

"Knowledge is power" - France is Bacon

manul

  • Участник
  • *****
  • Публикации: 16
    • Профил
Re: LKM rootkit
« Отговор #13 -: Nov 12, 2008, 15:34 »
Цитат
root@wattman:/home/manul/Desktop/rktest# cat make.err
/home/manul/Desktop/rktest/rktest.c: In function ‘hacked_chdir’:
/home/manul/Desktop/rktest/rktest.c:33: warning: unused variable ‘tsk’
/home/manul/Desktop/rktest/rktest.c: In function ‘mygettable’:
/home/manul/Desktop/rktest/rktest.c:68: warning: format ‘%x’ expects type ‘unsigned int *’, but argument 3 has type ‘long int **’
/home/manul/Desktop/rktest/rktest.c:73: warning: assignment makes pointer from integer without a cast
/home/manul/Desktop/rktest/rktest.c:75: warning: assignment makes integer from pointer without a cast
/home/manul/Desktop/rktest/rktest.c:54: warning: unused variable ‘b’
/home/manul/Desktop/rktest/rktest.c:51: warning: unused variable ‘a’
/home/manul/Desktop/rktest/rktest.c: At top level:
/home/manul/Desktop/rktest/rktest.c:94: warning: function declaration isn’t a prototype
/home/manul/Desktop/rktest/rktest.c:115: warning: function declaration isn’t a prototype
/home/manul/Desktop/rktest/rktest.c: In function ‘exitme’:
/home/manul/Desktop/rktest/rktest.c:121: warning: assignment makes integer from pointer without a cast
/home/manul/Desktop/rktest/rktest.c: In function ‘__exittest’:
/home/manul/Desktop/rktest/rktest.c:129: warning: return from incompatible pointer type
/home/manul/Desktop/rktest/rktest.c: At top level:
/home/manul/Desktop/rktest/rktest.c:18: warning: ‘tst’ defined but not used
/home/manul/Desktop/rktest/rktest.c:18: warning: ‘tst1’ defined but not used
root@wattman:/home/manul/Desktop/rktest#           

Eто...
Активен

gat3way

  • Участник
  • *****
  • Публикации: 6050
  • Relentless troll
    • Профил
    • WWW
Re: LKM rootkit
« Отговор #14 -: Nov 12, 2008, 15:45 »
Бафмааму, много странно.

Ако ти се занимава, пробвай да разкоментираш този ред от rktest.c:

//      printk("xname=%s\n",exname);

и после му дай пак ./inittest.sh

НЕДЕЙ ДА ИЗПЪЛНЯВАШ cd secretstring!!!

Просто след това rmmod модула и виж какво ще изпише в dmesg накрая. Може би има някакъв проблем когато се опитва да си вземе secretstring-a, защо - не знам. А може и да не е там проблема.

Иначе поне съм сигурен че sys_call_table[] успява да се презапише, щом ти изгърмява на cd <нещоси>...
Активен

"Knowledge is power" - France is Bacon