前篇：通达OA代码审计篇 - 11.7 有条件的任意命令执行
前篇中提到的漏洞在11.8版本中被完全修复后，我痛定思痛，从头开始找一个新的漏洞，于是就有了今天这个漏洞的诞生，但没想到的是，在保留到2021年初时，1月11号更新的11.9版本中再次被定向修复。
今天我们也来看看这一次的漏洞逻辑~
这是一个由有条件的任意用户登录+低权限文件上传+低权限目录穿越+低权限文件包含组成。可能是盯着国内OA的人太多了，这个漏洞在2020年9月28号的11.8版本中被更新修复，比较可惜的是，一次更新修复了全部的漏洞逻辑，不禁令人惊叹。
今天就一起来看看整个漏洞的逻辑~
反序列化漏洞是PHP漏洞中重要的一个印象面，而反序列化漏洞的危害则需要反序列化链来界定，如何挖掘一条反序列化链，往往成为了漏洞挖掘中最浪费时间的部分。
而和挖掘漏洞一样，建立在流敏感分析基础上的自动化白盒漏洞扫描技术，依赖数据流中大量的语法节点数据，通过合理的分析手段，我们就可以回溯分析挖掘漏洞，而挖掘php反序列化链也一样，只要有合理的分析思路，那么我们就可以通过分析数据流来获得我们想要的结果。
今天我们就来一起聊聊，如何把人工审计转化成自动化挖掘方案吧~
将时间还原到2019年6月之前，扫描器的世界大多还停留在AWVS这样的主动扫描器，被动扫描曾被提出作为浏览器插件火热过一段时间，可惜效率太低等多种问题束缚着它的发展。随着Xray的发布，一款免费好用的被动扫描器从很多方面都带火了自动化漏洞扫描的风潮。
其中有的人将Xray挂在自己的常用浏览器上以图在使用的过程中捡漏，有的人只在日站的时候挂上以图意外之喜，也有人直接操起自己尘封已久的爬虫配合xray大范围的扫描以图捡个痛快。可以说配合xray日站在当时已经成了一股风潮。
市面上比较常见的组合crawlergo+xray中的crawlergo也正是在这种背景下被开放出来。
但可惜的是，建立在自动化漏洞挖掘的基础上，当人们使用相同的工具，而我们又没办法自定义修改，是否能发现漏洞变成了是否能发现更多的资产的比拼。建立在这样的背景下，我决定自己发起了一个开源的爬虫项目，这就是LSpider诞生的背景。
LSpider作为星链计划的一员，已经开源，工具可能并不算成熟，但持续的维护以及更新是星链计划的精神~
前段时间开源新版本KunLun-M的时候，写了一篇《从0开始聊聊自动化静态代码审计工具》的文章，里面分享了许多在这些年白盒静态扫描演变过程中出现的扫描思路、技术等等。在文章中我用了一个简单的例子描述了一下基于.QL的扫描思路，但实际在这个领域我可能只见过一个活的SemmleQL（也就是CodeQL的原型）。这篇文章中我也聊一聊这相关的东西，也分享一些我尝试探索的一些全新的静态扫描方案。
本文提到的小demo phpunserializechain作为星链计划的一员开源，希望能给相关的安全从业者带来帮助。
本文会提及大量的名词，其中如有解释错误或使用不当欢迎指正。
自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地试错，不断地思考，于是才有了现代伟大的科技时代。在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。
这一次我们就一起聊聊自动化代码审计的发展史，也顺便聊聊如何完成一个自动化静态代码审计的关键。
前两天看了今年Geekpwn 2020 云端挑战赛，web题目涉及到了几个新时代前端特殊技巧，可能在实战中利用起来难度比较大，但是从原理上又很符合真实世界的逻辑，这里我们主要以解释题目为主，但是也探索一下在真实场景下的利用。
本文初完成于2020年3月31日，由于涉及到0day利用，所以于2020年3月31日报告厂商、CNVD漏洞平台，满足90天漏洞披露期，遂公开。
前几天偶然看到了一篇在hackone上提交得漏洞报告，在这个漏洞中，漏洞发现者提出了很有趣的利用，作者利用GMP的一个类型混淆漏洞，配合相应的利用链可以构造mybb的一次代码执行，这里我们就一起来看看这个漏洞。
https://hackerone.com/reports/198734
以下文章部分细节，感谢漏洞发现者@taoguangchen的帮助.
3个没用的Xss
以下是一篇不完整的文章，主要记录了在审计过程中的一些记录，在面对这类复杂的代码审计的时候，一旦被打断或者过后重新复习都会花费巨大的代价，所以这次稍微记录了一下结构。
以下笔记适用于 Roundcube mail 1.4.4
周末看了一下这次空指针的第三次Web公开赛，稍微研究了下发现这是一份最新版DZ3.4几乎默认配置的环境，我们需要在这样一份几乎真实环境下的DZ中完成Get shell。这一下子提起了我的兴趣，接下来我们就一起梳理下这个渗透过程。
与默认环境的区别是，我们这次拥有两个额外的条件。
1、Web环境的后端为Windows
2、我们获得了一份config文件，里面有最重要的authkey
得到这两个条件之后，我们开始这次的渗透过程。
以下可能会多次提到的出题人写的DZ漏洞整理
在经历了两次对Chrome Ext安全的深入研究之后，这期我们先把Chrome插件安全的问题放下来，这期我们将一个关于Chrome Ext的番外篇 – Zoomeye Tools.
这篇文章让我们换一个角度，从开发一个插件开始，如何去审视chrome不同层级之间的问题。
这里我们主要的目的是完成一个Zoomeye的辅助插件。
author: LoRexxar@Knownsec 404Team & Dawu@Knownsec 404Team
这应该是一个很早以前就爆出来的漏洞，而我见到的时候是在TCTF2018 final线下赛的比赛中，是被 Dragon Sector 和 Cykor 用来非预期h4x0r’s club这题的一个技巧。
http://russiansecurity.expert/2016/04/20/mysql-connect-file-read/
在后来的研究中，和@Dawu的讨论中顿时觉得这应该是一个很有趣的trick，在逐渐追溯这个漏洞的过去的过程中，我渐渐发现这个问题作为mys...
题目本身不难，但是比较麻烦的就是两点，一是没给代码，后面怎么merge全靠猜，二是题目的cache严重，中间很多测试都被别人干扰，第一天的下午及其严重，基本上开始很多测试都被别人带跑偏了…
下面我就来梳理一下我的正常思路…
在2019年初，微软正式选择了Chromium作为默认浏览器，并放弃edge的发展。并在19年4月8日，Edge正式放出了基于Chromium开发的Edge Dev浏览器，并提供了兼容Chrome Ext的配套插件管理。再加上国内的大小国产浏览器大多都是基于Chromium开发的，Chrome的插件体系越来越影响着广大的人群。
在这种背景下，Chrome Ext的安全问题也应该受到应有的关注，《从0开始入门Chrome Ext安全》就会从最基础的插件开发开始，逐步研究插件本身的恶意安全问题，恶意网页如何利用插件漏洞攻击浏览器等各种视角下的安全问题。
上篇我们主要聊了关于最基础插件开发，之后我们就要探讨关于Chrome Ext的安全性问题了，这篇文章我们主要围绕Chrome Ext的api开始，探讨在插件层面到底能对浏览器进行多少种操作。
在2019年初，微软正式选择了Chromium作为默认浏览器，并放弃edge的发展。并在19年4月8日，Edge正式放出了基于Chromium开发的Edge Dev浏览器，并提供了兼容Chrome Ext的配套插件管理。再加上国内的大小国产浏览器大多都是基于Chromium开发的，Chrome的插件体系越来越影响着广大的人群。
在这种背景下，Chrome Ext的安全问题也应该受到应有的关注，《从0开始入门Chrome Ext安全》就会从最基础的插件开发开始，逐步研究插件本身的恶意安全问题，恶意网页如何利用插件漏洞攻击浏览器等各种视角下的安全问题。
第一部分我们就主要来聊聊关于Chrome Ext的一些基础。
国外安全研究员 Andrew Danau在解决一道 CTF 题目时发现，向目标服务器 URL 发送 %0a 符号时，服务返回异常，疑似存在漏洞。
2019年10月23日，github公开漏洞相关的详情以及exp。当nginx配置不当时，会导致php-fpm远程任意代码执行。
下面我们就来一点点看看漏洞的详细分析，文章中漏洞分析部分感谢团队小伙伴@Hcamael#知道创宇404实验室
最近在研究一些Java相关的问题时候，虽然有能力读java的代码，但是从没深入了解过Java的我不免总是在各种只有Java上才有的特性上栽坑，于是忽然觉得可能需要了解一些java的漏洞，本篇文章没有太多干货，主要是自己在研究过程中的一些记录吧。
ps:在分析过程中觉得S2的官方真是傻逼，东填一下西补一下还指望能修复漏洞，真是不懂…
2019年4月15号，gitea曾爆出过一个漏洞，恰逢当时对这个漏洞比较好奇就着手去研究了一下，漏洞的描述是这样的：
models/repo_mirror.go in Gitea before 1.7.6 and 1.8.x before 1.8-RC3 mishandles mirror repo URL settings, leading to remote code execution.
在和朋友@hammer的一同研究下，成功控制了git config的内容，但是在从git config到RCE的过程遇到了困难，就暂时搁置了，在过了几个月之后，偶然得到@Lz1y和@x1nGuang两位大佬的启发，成功复现了这个漏洞，下面我们就来仔细研究下这个问题。
在2019年7月7日结束的WCTF2019 Final上，LC/BC的成员Pavel Toporkov在分享会上介绍了一种关于redis新版本的RCE利用方式，比起以前的利用方式来说，这种利用方式更为通用，危害也更大，下面就让我们从以前的redis RCE利用方式出发，一起聊聊关于redis的利用问题。
https://2018.zeronights.ru/wp-content/uploads/materials/15-redis-post-exploitation.pdf
