Aggregator
CVE-2012-2539 | Microsoft Word 2003/2007/2010 Rich Text Format resource management (MS12-079 / Nessus ID 63226)
CVE-2012-2550 | Microsoft Works 9.0 Document memory corruption (MS12-065 / Nessus ID 62460)
CVE-2012-2552 | Microsoft SQL Server up to 2012 Report Manager cross site scripting (MS12-070 / Nessus ID 62465)
CVE-2012-2551 | Microsoft Windows 7/Server 2008 R2 Kerberos denial of service (MS12-069 / Nessus ID 62464)
CVE-2012-2582 | OTRS up to 2.4.13 HTTP-EQUIV="CONTENT-TYPE cross site scripting (dsa-2536 / VU#582879)
CVE-2013-3631 | NAS4Free 9.1.0.1.798/9.1.0.1.804 exec.php code injection (VU#326830 / EDB-29320)
CVE-2012-2653 | Lawrence Berkeley National Laboratory arpwatch 2.1a15 Remote Code Execution (dsa-2481 / Nessus ID 74689)
CVE-2012-2664 | Red Hat sos 2.2-18 Configuration File credentials management (RHSA-2013:1121 / Nessus ID 69162)
jwt伪造身份组组组合拳艰难通关
现在的攻防演练不再像以往那样一个漏洞直捣黄龙,而是需要各种组合拳才能信手拈来,但是有时候使尽浑身解数也不能称心如意。
前期信息收集首先是拿到靶标的清单
访问系统的界面,没有什么能利用的功能点
首先进行目录扫描,扫描发现存在xxx.zip的文件放置在web目录上
一般zip文件大部分情况都是开发运维人员做系统维护时留下的备份文件,在系统上线后并没有将其删除,于是底裤(即源代码)都直接给到了攻击者
来到这一步都以为是一路高歌,轻松拿下,没想象到是跌宕起伏伏伏伏伏......
先使用wget下载zip文件,文件总共200+mb,很有概率是源代码的打包
从文件内容可判断,该系统是使用的.net开发,可通过dnspy进行审计
文件上传漏洞审计拿到源码后的第一个思路是寻找文件上传漏洞
果不其然在源码中找到uploadimg接口,发现未对上传的文件格式进行过滤
实际访问接口发现,怎么改变文件格式、文件内容、Content-Type、还是各种变种传输都无济于事。
返回包永远是{"Status":1,"Data""null}
运维实在是坏呀~
Sql注入漏洞审计第二个思路就是找注入
但是代码中定义了一个SqlChecker全局的类,强制处理所有用户传参,找注入这个方向有有点难啃了
系统用户信息遍历找到/api/user/getusers接口
接口没有做鉴权,构造请求包发送,返回包返回系统所有用户信息
其中用户信息包括姓名、出生日期、微信账号、手机号码、邮箱、密码等等
伪造jwt_token获取系统管理员-拿下靶标源码获取到jwt_token的secret
但是该secret不是可读性文本,估计是随机生成的byte字节序列,因此不能自行使用cyberchief或者其他工具将token直接生成
这里有个坑点:开始是使用gpt生成的脚本进行secret的读取和token的生成,发现gpt在处理字节上面有点问题,生成的jwt_token不能使用,于是自行编写了个py脚本进行jwt_token的构造,首先我们将字节序列做16进制的转化,为了python能够使用bytes.fromhex()函数读取16进制化的secret,然后根据上面读出的用户信息,伪装admin账号身份,并设置一个较长的ExpireTime
拿到jwt_token之后,要如何使用才能拿到后台呢,这里首先要明白该系统的登录鉴权机制
由于他存在注册功能,我们便可在自行注册一个账号,然后进行登录,查看认证处理流程
从数据包里面得知,登录成功后会返回jwt_token和一些与用户相关的一些信息,前端会根据返回的身份信息,跳转到对应的页面,并且功能接口都会带上jwt_token进行请求以便获取系统数据
了解清楚后,就开始进行身份伪造,首先去后台登录系统
将登录返回包的内容替换为管理员账号的token(从python脚本中生成)和管理员用户的身份信息
通过鉴权后,终于成功获取管理员后台,靶标5000分到手,哈哈
总结本次渗透从惊喜到怀疑到失落,总的来说就是“山穷水尽疑无路,柳暗花明又一村”。
如果只是死磕文件上传、SQL注入这些能够快速获取权限的洞,反而有时会错过一些有用的信息,毕竟比赛中分数才是最要紧的,如何高效快速拿下靶标才是第一要领。
同时,代码审计的过程中要结合系统功能来多方面评估,本次挖洞也是先认真理解了系统的登录认证机制,才知道有jwt鉴权这种方式,从而萌生在代码中找jwt secret的想法,也才能把快到手的分数牢牢抓在自己手中。
jwt伪造身份组组组合拳艰难通关
DolphinScheduler and SeaTunnel VS. AirFlow and NiFi
CVE-2012-2665 | LibreOffice 3.5.0/3.5.1/3.5.2/3.5.3/3.5.4 Encryption memory corruption (Bug 826077 / Nessus ID 68591)
CVE-2012-2668 | OpenLDAP up to 2.4.31 Libraries tls_m.c information disclosure (Bug 825875 / Nessus ID 69607)
CVE-2012-2671 | Rtomayko Rack-cach up to 1.1 Rack::Cache Remote Code Execution (Nessus ID 59379 / ID 165509)
CVE-2012-2673 | Boehm-Demers-Weiser Garbage Collector prior 5.0 malloc malloc.c GC_generic_malloc_ignore_off_page numeric error (RHSA-2013:1500 / Nessus ID 70754)
CVE-2012-2677 | boost pool 1.0.0/2.0.0 malloc ordered_malloc numeric error (RHSA-2013:0668 / Nessus ID 68794)
CVE-2003-0814 | Microsoft Internet Explorer up to 6.0 SP1 JavaScript href privileges management (VU#326412 / Nessus ID 10861)
【总结】注册码泄露原理以及例题
题目给了小明的机器码:1653643685031597
用户user_id:xiaoming
可以看到题目采用了SIMD指令集
该指令格式在CTF和攻防对抗中经常出现,可以提高执行效率的同时也可以增加逆向的难度。
对于此类指令和题目,我们分析的方法是:遇到查意思,查的多了就跟看正常代码一样,采用动态分析。
机器码修改将内置的机器码改为题目给的:1653643685031597
修改成功:
得到flag的时候跟machine这个有很大关系。
machine_id处理
在这个加密函数中
发现了MD5特征
经过动调拿到函数加密后的结果
与我们的猜测是相符的
可以发现最终md5(机器码)变成
user_id处理
和调试machine加密一样,最终MD5(user_id)变成:
最终处理经过之前相同的加密
变成这个数字:1228240365737281
然而这还没完,居然进行两次相同加密
再次加密后的结果:0502036271810858
可以发现此题出的很好,利用了密码比较的漏洞,没有将密文给出,而是将生成的密文在中间给出,从而造成了数据泄露。
得到flag回顾加密流程,可以发现
f(key) = f( f( f(md5(machine)) + f(md5(user_id)) ) )
那么题目给了得到flag的machine和user_id,可以得出
Key =f( f(md5(machine)) + f(md5(user_id)) )
所以最终flag:
flag{1228240365737281}