⑨BIE - 渗透
type: channel
link: https://9bie.org/index.php/tag/渗透/
items: 弱口令惨案
items: 某OJ渗透纪实
items: DLL劫持的白利用加载

弱口令惨案
type: item
date: 2020-11-20T18:13:00+08:00
description: 开始闲着无聊，在fofa上搜些奇怪的东西完，然后一个奇怪的东西引起了我的注意重点是这次是一连好几个一起出现，我想着可能有好玩的了。就开始随手测试了起来弱口令一连七八个站，随手试试admin/admin,admin/123456这类密码，在我打开第二个站的时候成功进去了，界面是这样的惯例，试图getshell，在节目编辑这里，我看到了一些奇怪的东西这个jsp就十分的灵性，直接点击编辑，修改jsp代码，光速getshell挖洞getshell下来了，那么肯定垂涎其他站啊，毕竟好多站都是这个cms，而且里面还有这么多台机器。首先进数据库看了下用户。很好，sha1加密，解得开的登不上，解不开的。。。那就解不开了并没有什么通用密码，而且访问所有jsp都会跳转到首页，没办法，只好先去翻配置文件直接暴露了个上传接口，lucky，二话不说打开看看可以访问，不怕你安全性高，就怕你全部路由都需要验证。立刻下载源码拉进ld-gui去审计看看爷傻了，任意文件上传，只要带mp3在文件名任意位置就能上传任意格式的文件。这时候我们再回到配置文件只设置了jsp是要跳转。。然而你忘了jspx。。于是乎好的这套的控制器基本就全都拿下来了反日小鸡既然控制器都解决了，辣么接下来肯定是想办法日到小鸡了啊，毕竟这都是广告控制牌。十分的好玩。机器数量还不是一般的多首先我们先看远端管理功能，发现了有些什么打开vnc/teamview这些功能跟进源码发现并没有什么软用，这时候我们把目标转向广告分发功能发现了下载这个关键词，我们大胆猜测一下，虽然这个预览是本地显示jsp路径的，按照逻辑上来讲应该是远程访问这个地址然后加载广告，那么有了这个下载功能会不会是本地加载？二话不说打个写个html下去远程查看结果人家真的显示了html，辣么二话不说，打个xss下去结果人家真tmd是本地jsp环境加载的。直接写个反弹jsp的shell上线成功直接修cs里去小鸡渗透--内网漫游本来这时候应该先审计小鸡源码的然后先把小鸡都拿了，然鹅我看到了这玩意有域，就先搞起来了先mimiktz读凭据，然后用cs自带的扫描器扫内网，目前手头只有一个凭据然后用这个凭据批量登录最后发现，只有同计算机名的机器上线了进去看了下似乎都是广告机之后，对着各个Ladon和各种工具走起，发现了10,11,40,50,150这些内网网段，初步计算下来，估计至少有500台。使用MS17010先跨网段耍一耍。随便日了几台发现这似乎是有规律的，都是[a-z][a-z]mgr01开头的密码，这还不立刻SmbScan，然而手头机器拉跨，而且半夜机器会自动下线就很烦于是乎我就关机了。然后第二天一打开我淦，当场抓获，管理员tmd在杀毒。上了个MSE，虽然很好过，但是也对我们造成了不小麻烦。因为前几天都是用cs的小鸡直接打的估计有写管理机进得去但是正好被杀了于是乎被管理发现了。十分的烦。然后我花了点时间好不容易整出个可持久化的免杀工具，也就是这个：https://github.com/9bie/shellcode然后等我万事俱备再上线一看tmd被管理员降权了，可恶。wdnmd，不过最后好在隔壁217机器没被降权，继续用终端机下发了个马过去然后机器又关机了第二题，经过几天研究，在那么多ms17010中，我们发现除了10.8是08，其他都是win7并且都在域内后面带.LOCAL，于是乎我们怀疑10.8是关键服务器，然而除了第一次打进去之后掉线之外，这台服务器就再也没被我们打进去过。九世, [28.11.20 02:10] 192.168.10.8 MS17-010 SHAREPINT [Win 2008 R2 Standard 7600] 192.168.20.147 MS17-010 KS16POS47 kaohsiungtw.local [Win Embedded Standard 7601 SP 1] 192.168.20.119 MS17-010 KS16POS19 kaohsiungtw.local [Win Embedded Standard 7601 SP 1] 192.168.20.117 MS17-010 KS16POS17 kaohsiungtw.local [Win Embedded Standard 7601 SP 1] 192.168.20.110 MS17-010 KS16POS10 kaohsiungtw.local [Win Embedded Standard 7601 SP 1] 192.168.40.51 MS17-010 TCKIOSK01 tigercitytw.local [Win 10 Pro 10586] 192.168.40.52 MS17-010 TCKIOSK02 tigercitytw.loc…

某OJ渗透纪实
type: item
date: 2020-06-11T14:17:00+08:00
description: 并没有什么技术含量，纯粹就是玩个黑盒的过程。挺有意思的，所以就写下来了。起因天台在群里说，他们那有个OJ是用windows的当然二话不说上来看看咯。开整之前大致想出流程，判断是否容器判断是否出网第一因为是用windows所以有点希望，就来验证第二个看看。bypass先找个时间长点的题目上去提交代码。能用的有C/C++/G++/JAVA/C#以及PASCAL试了一下，C/C++没有windows.h，基本的system等函数就直接reset了。估计有一些防火墙。运气好，发现C# 能执行api？？？这下好说了，shellcode走起。直接参考这个C#加载shellcode提交，运行，之后cs上线了但是10s一过就被k了。原本是想找个能自动复制的shellcode，或者是干脆直接exe2shellcode然后编码到代码里提交上去写出结果提交代码有长度限制，最多6kb，只能继续在shellcode上整活了。那么继续，我们换个思路。我们把自己复制一个，然后用api把自己运行不就行了？经过测试之后，发现，CreateProcess这个api可以用，shellExecute这些倒是被reset了。那么接下来就简单了测试之后发现，只有本体线程上线了。。。复制之后的那个没上线？这就很尴尬。现在有3个猜测Temp文件夹没权限CreateProcess并不能运行本体不是exe而是某种动态执行的东西，所以复制本体出去压根不是正确的PE文件总体来说就这三种情况，那么我们该怎么排查呢？伪黑盒测测oj也不是完全黑盒，oj也是有返回结果的其中我们只需要关注Judge Status，Exe.Time,Exe.Memory这些就行前两个我们是可以手动控制结果，后面一个Memory是判断我们程序是否正确运行。那么接下来就简单了。我们可以手动一个选择支(if)，达成某种目标，就给出正确答案，或者超时等等。我们先判断程序是否复制到了Temp文件夹下面，如果复制到了那么就直接Sleep到超时。if (File.Exists("C:\\WINDOWS\\Temp\\asd.exe")) { System.Threading.Thread.Sleep(2000); return; }else{return;}经过测试之后发现，文件不存在。程序并没有超时，直接return了。继续判断扩展名string filename = System.IO.Path.GetFileName(szPath); if(Path.GetExtension(fileName)==".exe"){System.Threading.Thread.Sleep(2000);}发现超时，说明文件确实被编译成exe了。那么既然temp目录没有权限，那么我们就直接复制到本地目录不就行了嘛。经过修改代码之后，提交运行。这次倒是上线了两个。但是依旧是过了10s，这两个程序同时掉线了。预测是被k了。这就很奇怪了。难道TMD学360还能判断进程链？还是说有什么组策略？既然这样，我们就换个方法，既然它会k进程链，那么我们就注入到不是我们创建的进程不就行了嘛？经过测试，Process这个关键字没被拦截，那么Process[] processes = Process.GetProcessesByName(processName);这个方法应该也不会被拦截，试了一下果不其然。这oj真的有做过滤嘛emmm，不过能调用api本来也就很奇怪了吧。依旧同样的方法，判断explorer.exe是否存在，然后找到它的pid。这里要注意点，可能找到的不一定是guest用户的explorer也许是其他用户的，我们不一定有权限注入。所以是循环查找。然后就是远程线程注入。很好，自信满满，提交运行。结果：？？？？换了x64/x32的shellcode都不行，msf的也试过了。全TMD都不行。我本地测试一下也奇怪的奔溃了。但是用C++写的那份却可以运行。怪事。不得已，只能上CPP了，还是CPP用的顺手。不过在此之前只能祈祷这上面能用内联汇编提交了个#include<stdio.h> int main(){__asm{NOP;}return 0;}上去，发现编译通过了！！！不就是不能用windows.h嘛，小事。之前想过，不能用windows.h最大的问题是什么？不能调用winapi嘛。然而懂计算机的都知道，我们只需要知道函数的地址，然后手动call不就能调用了嘛。和这种情况类似的有什么呢？对，就是shellcode。直接PEB或者SEH查找k32.dll的地址然后再找到LoadLibrary和GetProcAddress的地址，那么winapi不就是随便用了吗？因为仅仅是不能用windows.h，和我另外一篇 自己动手打造一份熊猫烧香 ，还是有点区别…

DLL劫持的白利用加载
type: item
date: 2019-12-30T00:51:00+08:00
description: 学到了一个新的技巧。和lpk.dll类似，有些文件会自动加载目录下面的dll。并且这些文件是经过授权且加入白名单的程序。例如WINWORD.exe。其他的待收集，只是记录一下