红客解密程序 暗网编程
27.4K subscribers
967 photos
12 videos
1 file
56 links
渗透测试,#删库,数据删除 拿数据库 木马注入 破解,提权,Dns动持
Download Telegram
这足以确认我们获得了命令执行权;我们及时通知 security (at) packagist.org 并且没有试图提升权限。
通过入侵官方 Cask 存储库在 Homebrew 中实现远程代码执行

在Homebrew/homebrew-cask存储库中,可以通过混淆 Homebrew 项目开发的自动拉取请求审查脚本中使用的库来合并恶意拉取请求。
通过滥用它,攻击者可以在使用 的用户机器上执行任意 Ruby 代码brew。

一天下午,在下一个约会1之前我还有一点时间,所以我决定在 HackerOne 上寻找一个有趣的程序。
因为我想在我使用的软件/服务中找到一个漏洞,所以我在电脑上四处张望,这个brew命令引起了我的注意。
然后,我记得我在 HackerOne 上看到了一个名为 Homebrew 的程序,所以我决定在其中找到漏洞。

为了选择目标,我查看了漏洞披露计划的政策页面。我注意到Homebrew/homebrew-*存储库在范围内。
由于我不擅长阅读复杂的 Ruby 代码,我决定在 中查找漏洞Homebrew/homebrew-
Skywalking远程代码执行漏洞预警

Skywalking历史上存在两次sql注入漏洞,CVE-2020-9483、CVE-2020-13921。经过源码分析,发现两次sql注入漏洞修复并不完善,仍存在一处sql注入漏洞。(该请求无页面入口,需要根据graphql配置文件手动进行请求构造,或许这就是官方遗漏该注入点的原因)

Skywalking默认配置下使用的数据库为h2,且使用sa权限启动。

另一个LINK_SCHEMA函数可以指定并发起一次jdbc或者jndi请求,但由于目标环境中无tomcat和springboot依赖,所以在高版本jdk中也无法进行通用的jndi利用,需要在本地依赖中寻找reference链。

于是我们可以先利用任意文件写入函数在classpath中写一个恶意类,然后再使用LINK_SCHEMA函数来加载这个恶意类,实现远程代码执行。
UNION 注入
和其他类型的数据库一样,基本没什么差别

先通过 order by 查当前表的 column 数量,13 返回正常,14报错,说明 column 有 13 个。注入出数据库账号密码
报错注入
主流的报错注入方式主要分为两类。

一类是 mysql、Oracle 这种使用自带函数使错误抛出的信息中携带参数值。另一类是 sqlserver 这种转型报错。

因为转型在这里并不适用,所以开始看一些函数的源码。

其中我关注到了 LOAD_FILE函数,发现它会把参数当做文件去读取,一旦遇到文件无法读取的情况就会把文件路径带入到报错信息中输出。

从源码中来看就是文件没读到,抛出了一个异常,在message中把这个路径给带了出来。
布尔盲注
布尔盲注主要通过页面返回的正常与否判断SQL执行的情况。

其他数据库的盲注用到的函数 hsqldb 基本都有。

如:SUBSTR、length、HEX、DECODE等。

其中DECODE就相当于 mysql 的IF。
decode(user(),'SA',1,0)
这条SQL的含义是“如果user()的值等于'SA'则返回1,否则返回0”

再带入到盲注脚本就很好理解了,运行盲注脚本就可以查到SQL结果
CVE-2021-3156:Sudo 中的基于堆的缓冲区溢出(Baron Samedit)


技术细节
如果执行Sudo以“shell”模式运行命令(shell -c命令):

通过 -s 选项设置 Sudo 的 MODE_SHELL 标志;或者
通过 -i 选项设置 Sudo 的 MODE_SHELL 和 MODE_LOGIN_SHELL 标志;然后,在 Sudo 的 main() 的开头,parse_args() 重写 argv(第 609-617 行),通过连接所有命令行参数(第 587-595 行)并使用反斜杠转义所有元字符(第 590-591 行):之后,在 sudoers_policy_main() 中,set_cmnd() 将命令行参数连接到基于堆的缓冲区“user_args”(第 864-871 行)并取消转义元字符(第 866-867v 行),“以便 sudoers 匹配和记录目的”
Apache Shiro权限绕过漏洞分析(CVE-2020-17523)

Apache Shiro是一个Java安全框架,它可以用来执行身份验证、授权、密码和会话管理。
在Shiro与Spring进行组合应用时,两者在对URI的处理中存在差异,常常导致Shiro认证绕过问题。
CVE-2020-17523复现
非漏洞作者,所以只能半猜测地复现该问题。先上payload:
> curl -v "http://host/admin/%20"
> curl -v "http://host/admin/%20/"

复现配置
SpringBoot + Shiro认证
(部分内容取自https://github.com/xhycccc/Shiro-Vuln-Demo/blob/main/shiro_cve-2020-13933)
向Spring中注入Bean
@Bean
ShiroFilterFactoryBean shiroFilterFactoryBean(){
ShiroFilterFactoryBean bean = new ShiroFilterFactoryBean();
bean.setSecurityManager(securityManager());
Map<String, String> map = new LinkedHashMap<>();
map.put("/admin/*", "authc");
bean.setFilterChainDefinitionMap(map);
return bean;
}
构造接口
@GetMapping("/admin/{name}")
public String admin(@PathVariable String name) {
return "admin page";
}
可见,在未经过认证的情况下,可以访问到admin page.