Posts

本文首发于先知社区 https://xz.aliyun.com/news/91353 回忆我这几年的失误和技术误解，并且分享有趣的故事—-几次打崩系统的故事，并且从中总结失败的教训，回忆稍显繁琐。本人已经没有参加任何比赛性质的攻防演练，均直接服务于项目，如有雷同，纯属巧合，所有渗透行为均合法授权，请不要瞎溯源。 第一次崩溃 大概是刚毕业出来工作的时候，在那个时候我还是个新手菜鸟，摆弄着各种大佬写的工具，那个时候，我开始熟悉冰蝎和Cobaltstirke，我发现了一个震惊我的功能，冰蝎居然能”一键上线CS“，对于不懂jni、汇编、架构和系统的那个时候的我，我震惊的，本地搭建环境测试了还成功了，轻松吊打360\微软DF，一个webshell 怎么可能打入EXE在内部执行？ 但是测试过程出了一个问题，在我的本机搭建的环境测试非常顺利，一键上线绕过了我们国内主流的杀毒，上线执行命令一切正常，而我朋友Arui的机器上测试，每次都会崩溃，我们开始争辩，但是你懂的，讨论不出什么结论，因为我们那个时候知识有限，我们当时不得不得出这个技术不稳定的错误结论，哈哈哈。 那么到底为什么？ 我和周边的朋友都是web出身的，基本上搞二进制的凤毛麟角，同时懂web和二进制这两个就更少了，22年当初问了一圈都没人能回答这个问题，过了几年，我开始掌握二进制的知识，然后翻阅了更新日志，看到了下面一条。 https://github.com/rebeyond/Behinder/releases 内存马shellcode注入前增加了CPU架构判断 4.1版本之前内存马shellcode居然没有CPU架构判断，所以答案已经很明晓，强制给32位的java塞一个64位的dll，架构都不一样肯定崩溃，也就是我同事的环境，可能还在用32位的java+windows测试环境，这要是实战，我们只能得出对面关闭了网站 我们再看一下源代码，这个是之前的64位和32位的判定： https://github.com/MountCloud/BehinderClientSource/blob/d146e76ec90dbb5f1454dd77ec8e2368b4eadf6f/src/main/java/net/rebeyond/behinder/ui/controller/ReverseViewController.java#L181 选择随机保存dll到如下目录 String remoteUploadPath = "c:/windows/temp/" + Utils.getRandomString((new Random()).nextInt(10)) + ".log"; 判定架构进入分支 (String)this.basicInfoMap.get("arch")).toString().indexOf("64") >= 0 是64位直接打入JavaNative_x64.dll，否则打入JavaNative_x32.dll if os == 64: inject JavaNative_x64.dll and shellcode else: inject JavaNative_x32.dll and shellcode 这样写修复了x86-64的问题，但是很明显，全世界有大量不同的架构，比方说ARM架构和RISC-V，这样就会直接进入inject JavaNative_x32.dll and shellcode打崩JVM 深入解释原因 等等，刚刚的就是正确的答案吗，崩溃的含义是什么？刚刚我们并没有解释清楚哪里崩了，对吧？已经是3年前的事情了，如果有dumpcrash的文件，我瞄一眼就能定位，但现在我只能尝试推测还原，让我们把问题分解开来，其实就是三部分：windows的问题、java自己的问题、载入的dll的问题： 首先，先理解JNI的本质只是调用LoadLibrary，一个64位的java.exe PE调用LoadLibrary加载32位的DLL是不会导致崩溃的，你可以编译一个64位的PE验证这一观点，它只会返回一个错误code回来，这可不会带崩进程和后续代码的执行逻辑： // demo.cpp : This file contains the 'main' function. Program execution begins and ends there. // #include <iostream> #include <Windows.h> int main() { std::cout << "SysWOW64 is 32 bit PE!\n"; LoadLibraryA("C:\\Windows\\SysWOW64\\ntdll.dll"); std::cout << "the lasterror is " << GetLastError() << std::endl; std::cout << "It is ok the countine execute code\n"; } 执行结果如下： ...

简单分享一下备考体验和经历，希望能帮到新入坑的师傅。 CRTO 价格和内容 CRTO（Red Team Ops）我是2023年买的，因为摆烂加兴趣转移（深入学习了一段时间的windows底层机制）2024年的国庆才考完拿下认证。那个时候买完就打折了，总共就花了4000块，加上lab可能就4500？打折可以更便宜。现在不给中国人买了，会验证信用卡的来源（听说可以使用虚拟信用卡绕过它这个限制，我那个时候，2023年还没有这个限制）。教材内容主要是域渗透相关的，和OSEP高度重合，可以去大纲看看，我这里就不赘述了。 这个地方 ：https://training.zeropointsecurity.co.uk/courses/red-team-ops 考试环境用的是最新的windows杀毒（没错，考试环境会一直更新，使用最新的windows版本和windows杀毒，我是自己提前写好了C++的加载器，在攻击机的环境里面编译使用，考试提供了编译环境），随着windows杀毒越来越强，CRTO的考试免杀绕过应该会越来越难。我没走教材的免杀方法，它免杀依赖Kit，不是很灵活，当然对于通过考试来说足够了。 教材讲解了很多Cobaltstrike的使用技巧，你就会发现CS是多么好用又稳定。内容总体来说就是域+免杀+CS的基本和进阶使用方法，价格非常实惠，当初刚毕业身上没什么钱，就买了这个。认可度的话可以看看这个，是官方Cobalt Strike Training Resources指定的课程，CRTO知名度应该后面会越来越高：https://www.cobaltstrike.com/support/training CRTO的浏览器网络问题 由于考试和CRTO lab环境一样，是给个浏览器去访问操作里面的工具，一线城市直连的质量还是不错的，都花钱买了CRTO了，也不缺几十块钱买好一点的专线梯子去操作。里面的机器配置和做lab是一样，体验算不算卡，也算不上流畅，不过比OSCP稳定多了。 CRTO考试经验 很难说到底要准备多久才能通过考试，我想，CRTO的lab要是能流畅完成，考过应该问题不大，我之前就有域渗透经验，复习了几周，准备好命令的笔记（我之前就研究了一段时间AD，严格来说我对AD、底层协议已经非常熟悉了）就预约了考试了，预约之后，你会在你的版面出现一个lab考试的环境，点进去里面有Readme说明，一定要仔细阅读。 考试给了四天时间，我在10点中起床开始考试，我花了1个小时多的时间配置完环境，下午4点左右我就拿到了60分，这足以通过考试，但是我是完美主义者，我决定继续深入研究； 我卡在最后一个域接近7个小时！最后一个域难的离谱，距离考试已经有一段时间了，我现在都记不清楚怎么横向过去的了，当时域横向的命令有问题，我花了很久的时间修复命令，修改工具的源代码排错。 我一天拿下了全部flag，满分通过了考试，哈哈哈哈。 时间没必要卡的太死，如果你累了就休息吧，关机可以省下一些时间，但是注意要做好权限维持，不然后面就掉线了，就很难受；如果你和我一样一天就做完，倒也没必要搞权限维持。最后一个域远远超过了教材里面的内容，不建议新手死磕，做不出来也正常，我现在去做也费劲。考试不需要写报告，交完Flag就等证书下来了。 划重点！一定学好域之间移动和MSSQL的模块! 不然肯定挂科。 考完邮件会发一个链接，然后你就能收到这个认证了： Update:现在教程改版了，这个经验不再适用。 OSCP价格和内容 我去年2024年底在官网买的一年的实验室，花了1w5左右，当时有20%折扣，听说又涨价了。这个认证可以说是越来越贵了，官方为了多赚钱也没办法，而且客户认可度也高，不得不得考了（笑），主要是这个认证可以去部分银行养老，哈哈哈哈，也许有一天我也去养老了，加上公司要接项目看这玩意。内容主要就是web、域、系统提权，现在这个教材版本还加了AWS的云，内容很丰富。 你应该不能体会到一个经常刷顶会演讲，被black hat、defcon、各路卷王的博客熏陶洗礼过的HACKER再去做sql注入、web\域基础的心态，还要被CTF的题目、兔子洞折磨，我TM直接裂开，对我来说太痛苦了，要知道现在现代红队，我们开发的工具都是指纹识别+POC高度精准了，OSCP挂科就就像大学生回去做高考题，还没考上现在的学校一样，这太丢人了。 我见过不少人就考了OSCP\OSEP再考CRTO，但是我这种老油条的经历情况太特殊了，哈哈哈，就反过来了。说实话我对这些内容相当熟悉，还是买了一年的，因为有两次考试机会。如果你买的一年两次，参加补考的价格是$249，可以参考这个： https://help.offsec.com/hc/en-us/articles/29840452210580-Changes-to-the-OSCP 为什么我第一次会失败？ 额，绝不是因为我技术不行或者实力不够，如果你硬要说我实力不行，那我也只能承认了，我要是修炼到了化神期还考这玩意干什么，早就飞升仙界了。纯粹是因为我缺乏练习，内功再深厚，招式不练习肯定是不行的，我的岗位是安全研究基本上就是云相关的研究—和这些题目相关性几乎就是0，加上OSCP也故意设计成就是要折磨考生，我TM大意了，没有闪，我当初第一次备考就过了一下oscp里面的实验室，pg是一个都没动，就匆匆上考场了，果不其然失败了（以前有一些幸运儿只练教程的实验室也能过，可能和抽到的题目难易度有关系，也有可能是OSCP+加强的考试难度？） 一定要做完 Proving Grounds Practice这个靶场，虽然很折磨，但务必做完，他送的实验室建议最后练习，因为对比真正的考试比较简单，可以考前增强一下自信心。备考就用这个折磨折磨吧 https://docs.google.com/spreadsheets/d/18weuz_Eeynr6sXFQ87Cd5F0slOj9Z6rt/ ，建议一定还要做完 基本上只能每天打靶练习肝了，没有任何捷径可以走，你就是老红队，研究员不做这里面的八股文一样难受，核心是—-你必须要猜出他的考点，然后做出来！但是3台单机是有无限可能的—-你必须24小时解开，这CTF对我来说太折磨了，限制时间的话也很考验心态。 这是另一个博主的观点，“That being said, as mentioned earlier, the OSCP is still the industry requirement for most offensive security roles in Singapore (and most other countries) - so if you’re looking to join an offensive security team, you will eventually have to bite the bullet and roll the dice on OSCP “—– https://gatari.dev/posts/certified-cert-collector/ ...

本文首发于先知社区，博客此版本内容稍有改动。 先知地址为： https://xz.aliyun.com/news/18560 本系列将记录我研究AWS安全相关过程的基础知识、攻击手法、威胁检测工程等相关技术和思考。先从基本概念、云架构、重点服务开始讲解，结合云的主要风险点和目前高频使用的TTPS攻击手法，最后再简要介绍威胁检测相关的工作和工作方向。个人水平有限，如有错误及时评论指出。 AWS 基础 为了方便新接触云的师傅，还是要先讲一下AWS的基础和环境搭建。首先个人研究，需要准备一张虚拟信用卡，然后去官网需要注册一个AWS账户，建议不要选中国区，选到海外，国内有很多限制。等注册完成登录了，就会进入类似下面这样的一个页面，相信大多数人和我一样，以前从来没接触过这玩意，面对一堆服务图标，绝对是一脸懵逼的状态 让我们慢慢熟悉一下基础概念，如果有系统架构或域渗透相关经验理解起来就会很快，没有也不慌，我们慢慢理解基础概念。 云计算概念 谈云总是离不开这几个概念-IaaS/PaaS/SaaS，方便新人入门就拿实现“发邮件”的来做类比： 基础设施即服务（IaaS）：IaaS提供服务器给你，你需要自己开发或购买邮件系统，自己搭建起来配置使用，自己运维管理，非常灵活，但也面临运营维护成本过高的问题。相当于你买了基础的地皮，提供了基础计算环境，但是搭建什么样子的建筑全看厂商自己。 平台即服务（PaaS）：PaaS相当于提供一个邮件平台，但是细节实现还需要开发调用服务的API，完善相关的功能，相比于IaaS就少了维护基础计算环境的问题，节约了一部分成本，对于企业开发来说非常方便。 软件即服务（SaaS）：SaaS相当于直接提供一个软件平台，类似QQ邮件直接注册一个QQ就能使用配套的服务，完全没有开发层面的负担，把软件更新维护交给了厂商实现，虽然大大节约了相关成本，但是也牺牲了开发层面的灵活性。 进入界面，想要探索或者查找服务，可以使用右上角的搜索界面，里面有大量服务分类：存储、计算、物联网等等 刚才截图页面的面板的服务分类从大类分，无非就是刚刚说这三种，虽然页面上的点击功能足够我们大多数交互，但是传统渗透都习惯于使用命令行来和AWS交互，省去了页面点击布局可能变动导致迷惑的问题。 一般来说我倾向使用AWS CloudShell去执行，只需要搜索里面查找点进去即可使用，它里面已经预装了AWS CLI，直接使用了当前的用户会话作为默认登录： 我们可以检查一下AWS的版本信息： aws --version 也可以检查一下当前用户的信息，这个命令相当于系统中的whoami，会返回一个json数据 aws sts get-caller-identity 它会返回三个字段： { "UserId": "AIDASAMPLEUSERID", "Account": "123456789012", "Arn": "arn:aws:iam::123456789012:user/pacutest" } 其中"Arn"字段的全称是Amazon Resource Name，亚马逊资源名称将作为一个唯一的值关联到特定的资源，很明显Arn里面就标注出来了user/pacutest这个用户名。 想要查看当前用户的权限策略可以使用： aws iam list-attached-user-policies --user-name pacutest 看到下面的没有，我们这个用户居然是管理员策略—AdminstratorAccess AdminstratorAccess策略默认可以访问所有资源，相当于超级管理员，这也是用的最多的AWS托管策略,我们阅读文档看看，文档左侧还有很多AWS托管的策略就不赘述了，记不住也没关系，需要用到的时候就查一下。 JSON 策略文档的内容如下,Effect设置为允许，Action和Resource使用统配符星号指代所有资源： { "Version" : "2012-10-17", "Statement" : [ { "Effect" : "Allow", "Action" : "*", "Resource" : "*" } ] } 值得注意的是，AWS的权限策略非常严格，如果没有主动授予查看用户本身的权限，甚至aws iam list-attached-user-policies 自己都是会被拒绝的，这要是放在windows和linux中简直就是不可思议的事情，如果类比到AD，我们有一个普通用户居然不能导出用户名列表，不能查找策略，简直就是瞎了一样，从这一点来看，云的渗透难度远远比AD更大，攻击面更加收敛。 ...

整理一下过去之前发现的一些小趣事，本文并非批评腾讯云，相关研究和时效性有关，不代表读者当前阅读和未来腾讯云的安全状态，但我分享欲望实在强烈，就在博客简单分享给大家。 无缓解的metadata导致SSRF漏洞默认即可打临时ak sk 之前研究AWS的时候，我发现有metadata的v2版本缓解了ssrf打iam metadata的情况，迁移到腾讯云上就是CAM 角色关联实例打metadata，但是翻找文档期间并未找到相关缓解建议，结合实际实例配置情况，最终得出结论—目前腾讯云没有缓解metadata的问题。 配置过程如下，可以看到我们配置压根没得选： 第二部设置网络和主机就可以看到 此处压根没有版本选择，只能直接选上： 如果绑定了CAM，终端可以直接访问，类似于： curl http://metadata.tencentyun.com/latest/meta-data/cam/security-credentials/ 腾讯云SSRF会被拦截，但是目前来说，WAF并不会阻断腾讯云自己的域名 —– metadata.tencentyun.com ，web ssrf漏洞依然可以直接打出临时ak sk ，对比之下aws的设计已经缓解了这个问题，由于SSRF无法控制请求头变成PUT，因此AWS的设计更加安全，而腾讯云在这一点上就不安全 默认策略放通所有地址 默认情况腾讯云放通icmp\ssh\rdp和内网所有访问，稍微比AWS策略更宽松，虽然这些也算不了什么大影响，但是如果服务器默认不出网，意味着相关无直接回显的漏洞将没有直接手段能确认漏洞存在，不出网极大提高了攻击门槛，腾讯云云上的默认网络策略比较宽松，如果有漏洞比较方便黑客操作。 不安全的存储桶名称，导致潜在的横向攻击 我们过一下存储桶的创建就很容易意识到这个问题，在创建存储桶的时候，观察到腾讯云 —实际上有固定的后缀– 1309XXXX，这个是非常明显的强特征；腾讯云自己也意识到默认域名存在安全风险，建议自己配置自定义域名： 黑客可以利用这一点，可以横向发起攻击，由于限定了存储域名的后缀，只需要不断爆破即可发现同意账户下新的存储桶，从而进一步攻击和收集目标环境的信息，访问一个不存在的将会提示NoSuchBucket： 存在根据权限情况会回显不同，这次是AccessDenied： 利用这个区别，可以把NoSuchBucket的过滤掉，然后爆破出存储桶，有不少存储都是没有ACL限制，直接访问即可获取桶内文件，这一点和我们做目录扫描其实没有区别，看字典是否强大，是否有直接列出文件的漏洞。 ffuf是我常用的选项，直接插请求包来fuzz，插入host，插入路径都行，得师傅们自己构造路径了： ffuf -request req.txt -w worldlist.txt 但是这一点真不能说是坏处，名称固定了后缀有效的防止了存储桶废弃之后导致潜在的供应链攻击，这一点腾讯算是加分，好坏中和了。 日志审计缺失，部分控制台事件默认不会被记录 观察到在控制台的策略中，使用鉴权模拟器进行的权限校验活动不会被腾讯云的日志审计收录，这对于黑客确定自己的权限有很大的帮助，在云内进行认证扫描的活动会被大大降低，目前社区没有广泛公开这项隐蔽扫描的技术，但可以遇见如果后续有人武器化这部分扫描原理会使得云内检测非常棘手 地址如下，目前没有现成的SDK可以直接调用，我已经没兴趣实现这部分认证和扫描的逻辑，感觉也是体力活没啥技术含量，也许可以用来规避蜜罐的AK SK？ https://console.cloud.tencent.com/cam/policy/simulate?entityType=role&keyword=CSIP_QCSLinkedRoleInGlobalScene 托管实例风险 云服务器有一个非常有意思的功能，可以托管实例到腾讯云上，托管过后的服务器可以执行命令、上传文件，是不是非常像我们用的C2里面的玩意？（笑），实际上不少黑客都喜欢用这个托管来做免杀（本身是白签名的二进制）加上合法流量，使得这个功能定位非常尴尬。如果本身企业在用腾讯云，要区分出来恶意的流量是非常困难的。 后记 上述也谈不上有什么技术含量，就不写总结了，写写感悟吧。在研究过程中，尤其是全新的，尚未有人踏足的领域，研究员必须自己积累大量的基础知识（我的意思是构建整个系统的逻辑），然后从中推演出其中的术法、神通，模仿他人的、复现他人的技术虽然能完成项目上的目标亦或者是其他目的，但终究止步于他人之道。 ...

最近换了电脑，博客已经一年多了，最近更新频率低了，后面会勤快一些把之前研究和学习的都分享出来，（主要是写的太乱了，不整理估计只有自己勉强看得懂，而且有些细节部分的东西时间隔得太长了，我都快忘干净了，整理一下对自己复习也有帮助）；先分享一下最初搭建的完整流程，这也是我能想到的最安全、最方便、最优雅的博客搭建方法，不出意外应该会一直用下去。 选取的原因 个人隐私考虑：Cloudflare Pages托管在Cloudflare上，不必自己购买服务器，使用的是Cloudflare的全球网络，不存在中心化的服务器，而且可以配置自己的域名，域名不会保留个人信息，会默认替换为Cloudflare的注册信息，而且可以有“电子邮件路由”功能，可以对外使用我自己的域名，启用邮件转发来隐藏我真实使用的邮件，提高一点点隐私和不必要的麻烦 博客安全考虑：背后博客用的是Hugo，Hugo纯静态的页面直接使得正面的攻击面收敛为0，不存在被常规漏洞打击和未来0day打击的风险，同时使用了Cloudflare的CDN，默认提供了强大的DDOS保护，不存在被打下线的风险，博客部署在Cloudflare全球网络上，整体安全系数接近绝对防御。 博客颜值考虑：且Hugo的主题很漂亮、也很丰富，如果看腻了也可以随时更换主题，轻松迁移更替 社区维护考虑：目前社区一直积极活跃，已经83kstar，业内公认的博客搭建方法，应该能繁荣好多年，虽然现在配置也很麻烦，但好在用的人多参考资料也多 搭建流程 前提准备： 注册一个Github账号 注册一个Cloudflare账户，需要信用卡 本地安装好Git，如下图 提前去 https://github.com/gohugoio/hugo/releases 下载好hugo的对应的二进制文件，并且把它的目录加入你的电脑的环境变量，这样后续方便切换不同 Github上创建博客的项目： 创建完毕后，记下你自己的这个，等会要用这个地址推送hugo 博客到项目中： hugo.exe version PS D:\blog\zeroday> hugo.exe new site zeroday Congratulations! Your new Hugo site was created in D:\blog\zeroday\zeroday. Just a few more steps... 1. Change the current directory to D:\blog\zeroday\zeroday. 2. Create or install a theme: - Create a new theme with the command "hugo new theme <THEMENAME>" - Or, install a theme from https://themes.gohugo.io/ 3. Edit hugo.toml, setting the "theme" property to the theme name. 4. Create new content with the command "hugo new content <SECTIONNAME>\<FILENAME>.<FORMAT>". 5. Start the embedded web server with the command "hugo server --buildDrafts". See documentation at https://gohugo.io/. ...