自从人类发明了工具开始，人类就在不断为探索如何更方便快捷的做任何事情，在科技发展的过程中，人类不断地试错，不断地思考，于是才有了现代伟大的科技时代。在安全领域里，每个安全研究人员在研究的过程中，也同样的不断地探索着如何能够自动化的解决各个领域的安全问题。其中自动化代码审计就是安全自动化绕不过去的坎。
这一次我们就一起聊聊自动化代码审计的发展史，也顺便聊聊如何完成一个自动化静态代码审计的关键。
前两天看了今年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
2019年6月11日，RIPS团队在团队博客中分享了一篇MyBB <= 1.8.20: From Stored XSS to RCE,文章中主要提到了一个Mybb18.20中存在的存储型xss以及一个后台的文件上传绕过。
其实漏洞本身来说，毕竟是需要通过XSS来触发的，哪怕是储存型XSS可以通过私信等方式隐藏，但漏洞的影响再怎么严重也有限，但漏洞点却意外的精巧，下面就让我们一起来详细聊聊看…
上周有幸去南京参加了强网杯拟态挑战赛，运气比较好拿了第二名，只是可惜是最后8分钟被爆了，差一点儿真是有点儿可惜。
有关于拟态的观念我会在后面讲防火墙黑盒攻击的writeup时在详细写，抛开拟态不谈，赛宁这次引入的比赛模式我觉得还蛮有趣的，白盒排位赛的排名决定你是不是能挑战白盒拟态，这样的多线并行挑战考验的除了你的实际水平，也给比赛本身平添了一些有趣的色彩（虽然我们是被这个设定坑了），虽然我还没想到这种模式如何应用在普通的ctf赛场上，但起码也是一个有趣的思路不是吗🙋.
Web 白盒sqlcms这题其实相对比赛中的其他题目来说，就显得有些太简单了，当时如果不是因为我们是第一轮挑战白盒的队...
2019年4月11日，zdi博客公开了一篇A SERIES OF UNFORTUNATE IMAGES: DRUPAL 1-CLICK TO RCE EXPLOIT CHAIN DETAILED.
整个漏洞的各个部分没什么特别的，巧妙的是，攻击者使用了3个漏洞+几个小trick，把所有的漏洞链接起来却成了一个还不错的利用链，现在我们就来一起看看整个漏洞.
2019年3月13日， RIPS团队公开了一篇关于WordPress 5.1.1的XSS漏洞详情，标题起的很响亮，叫做wordpress csrf to rce,
https://blog.ripstech.com/2019/wordpress-csrf-to-rce/
下面我们就来详细聊聊这个漏洞。
2月20号，RIPS团队在官网公开了一篇WordPress 5.0.0 Remote Code Execution，CVE编号CVE-2019-6977，文章中主要提到在author权限账号下，可以通过修改Post Meta变量覆盖、目录穿越写文件、模板包含3个漏洞构成一个RCE漏洞。
但在原文中，作者只大致描述了漏洞原理，其中大量的漏洞细节被省略，甚至部分的利用和后端服务器也有相当的关系，所以在复现的过程中遇到了各种问题，我们花了大量的时间分析代码，最终终于完全还原了该漏洞，其中部分关键利用点用了和原文有些许差异的利用方式（原文说的太含糊其辞，无法复现）。在下面的分析中，我会尽量按照复现过程中的思考方式及流程，以便读者理解。
感谢在复现、分析过程中一起的小伙伴@Badcode，帮助我修改了很多错误的@Venenof7、@sysorem,给我提供了很多帮助:>
