CTF Web 原创题三道

为不存在的校内赛出了三道(可能会被采用)的 CTF 题,主要是 Web 方向。

题一:easy_calc ,涉及 Node.js、SQL;

题二:easy_template,涉及 PHP;

题三:easy_pickle,涉及 Python。

提供各题 docker 环境,设计思路及具体 write-up;基于 Apache 2.0 License。

 


 

 

 


 

  • 题目环境

题一:附件 easy_calc.rar ,提供搭建好的环境网址与此附件(前端代码有所参考)

题二:附件 easy_template.rar仅提供搭建好的环境网址;(标题与考点完全无关)

题三:附件 easy_pickle.rar仅提供搭建好的环境网址。(总感觉比较鸡肋)

出于安全考虑,环境网址就不公开提供了,有兴趣的话可以自行搭建。

 

 


 

  • easy_calc

(同时提供 PDF 版:writeup_easy_calc.pdf

环境分析:./front/ 用于前端反代(非漏洞点),mariadb 为后端数据库(innodb 只读),./calc/ 为漏洞代码处;使用 node 19.3.0 高版本,mariadb-connector-nodejs 3.0.2 (此文章发表时的最新版本)。

关键代码片段 ./calc/index.js 如下:

注意到 Line 9 处有一个别样的参数:nestTables (默认为 false);

其效果为将当前查询的表名一并纳入结果中,如 select test_column from db.table_abc 时,返回值如下:

关注其源代码 /mariadb-corporation/lib/cmd/parser.js#L491

而在上面 #L268 处,当 nestTables 启用时这俩参数都直接从 select 的结果而来:

也就是说,有一种可能,当表名为 __proto__ 时,代码覆盖了 row 即 {} 的原型,造成原型链污染

即现在需要控制 SELECT 出来的表名为 __proto__ ,项名为任意变量(字符串)。

但由于这里的数据库是 read-only,无法对实际的表或项进行操作,于是注意到 SELECT AS 这种语法。

而这样虽可以控制项名,但由于 'any_value' 不是实际表中的实际项,所以结果中这一项的表名为空,不可控:

此时注意到有一种 select without from参考)的写法,在题目环境的 mariadb 表示为:

成功控制表名、项名及内容,至此即可污染环境中原型链上的任意变量,闭合括号的 payload:

这时注意到 calc/index.js 中已经给了一个 execFileSync 作为触发点,尝试污染其为任意代码执行:

新版 node 中默认使 options 为 kEmptyObject(/lib/child_process.js#L285),execFile 函数前新增了各种默认 options 参数为 null 或 false 的判断(#L336),但题目环境中的写法导致其可以被污染。

注意到 #L635 处,污染 options.shell 可以替换当前的可执行文件;#L645 处,污染 options.argv0 可以替换 argv0 即 cmdline;options.env 为 null 无法被污染,但 #L672 处这个 for 由于污染了 {} 的原型就会将所有被污染的变量都添加进去,因此环境变量实际上也是可控的。

但同时注意到题目环境中所有的可执行文件都被删除,只留了个 nodejs,想到 NODE_OPTIONS 可以用来注入 js 命令。

故污染如下的变量,即可任意代码执行:

但此时注意到 calc/index.js 是在 execFileSync 后才将结果写入 ./ret,故即使在 argv0 处将 /readflag 的结果写入 ./ret 也会被覆盖,无法得到回显。

发现题目环境中 docker 入口点为自定义程序 watcher ,观察其流程:

判断若执行超时则强制结束子进程(即 node)的执行。

此时注意到仅需让主程序 node index.js 执行超时即会被杀掉,./ret 的内容也就不会被覆盖。

写入 ./ret 后死循环即可,以下为 argv0 的代码内容:

最终的 payload:

出题后话:原型链污染上头了之后,在一个平静的午后,毫无征兆地就会想到 SQL 查询时也可能存在二维数组的覆盖。而 mysqljs/mysql 中使用了一个自定义 class 导致无法覆盖到上层原型链,pgSQL 玩不太明白,折中选择了 mariadb。另外,前端部分代码其实来源于某场比赛中遇到的某个 NodeJS 题,由于自己技艺不精,dockerode 还是第一次在那见到的,也算是一种启发吧(读书人的事情,怎么能说是……)。

 

 


  • easy_template

(同时提供 PDF 版:writeup_easy_template.pdf

环境分析:不提供附件,在 www.zip 处可以下到网站源代码。

功能不多,结构比较清晰,hello.php 为主入口点,template.php 为简单的模板渲染函数;

hello.tpl 为简单模板,支持两种格式:

首先得搞清楚 template.php 里那一堆正则到底是啥情况。

绑定到模板的参数(通过 GET 获取)首先经过 check_invalid_vars() 的过滤:

即不能含有 {\ /} ' ; 这四种样式,过滤了模板标识,插入变量后的标识及简单函数执行标识。

模板处理主循环位于 parse_template_string() 处:

可以发现这里存在一个关于 preg_match_all() 的返回值 $matches 的认识上的错误:$matches[0]$matches[1] 才分别对应完整的、括号内的表达式数组,按照如上函数的写法只能获取到第一个非贪婪匹配 \{ .*? /} 的结果,实质上等同于 preg_match(),避免了前后方同时替换的情况。

来看处理简单模板命令的函数 command_handler()

贪婪匹配 % .* % 作变量替换,并把替换后的结果用 ' 包住,错误同上但并不重要。

可以发现这里是重头戏,匹配类似 ^{\ func('para'); unsafe /}$ 这样的格式作简单函数执行,要点有:必须以模板标识起头结尾、仅有一个参数且必须用单引号括起、紧跟一个分号;如果有 unsafe 标识则位于分号之后。

当没有改动发生时,认为该部分模板已渲染完毕,检查模板标识内的单引号是否将所有字符都括起,最后删去单引号及模板标识并返回。

分析完毕,目标很明确:利用简单函数执行功能 getflag;由于分号无法被人工引入,为此只能尝试污染已有的 get_lucky_number() 为任意函数。

    1. 模板标识的再构造。倘若一直被拘束在原有的模板标识里,事情是进展不下去的,为此需要插入新的模板标识;比较直接的{\ /} 已被过滤,但注意到变量的标识符 % % 依然可以使用,且单引号最终都会被删去,于是采用拆分的转移方式S→'{A' ; A→'\B' 即( S→'{'\'B''' )。体现在题目环境中即为 n0={%n1% ; n1=\%n2% ; n2=...

    2. 绕过 str_replace()注意到处理函数的末尾不仅删去了单引号,还删去了头尾的模板标识;倘若直接按 1. 的方法构造,也无法存留。那么这里就是一个简单的绕过:同样的方法改为 {{\\ 即可。

    3. 控制单引号对齐。注意到处理函数末尾检查了模板标识内的单引号是否将所有字符都括起,而直接按照 1. 的方法构造,会产生诸如 '{'\'B''' 的字符串,按照非贪婪模式匹配,则有其中的 \ 未被括起,处理函数返回 undefined。应对措施也很简单:制造一对空单引号(等价替换)即可;也就是将 \B 替换为 \B 使其变为 '\B' ,此时的单引号便对齐了。体现在题目环境中即为 n0={%n1% ; n1=%n2% ; n2=\%n3% ; n3=...

    4. 跨越距离的 % %至此,已经能在 hello.tpl 的两处 %name% 构造出新的模板标识了;目标是替换第二处的 get_lucky_number() ,且模板处理从第一处开始。可谓说制造出新的模板(开始)标识就是为此:将第二处的 % % 纳入第一处的支配范围。正则是从左往右匹配的,如果此时第一处变为 {\ %,那么它将与第二处的后一个 % 形成匹配(因为是贪婪的),形成一个包含换行、空格等字符的变量,其仍可被替换。可以想到,hello.php 中的 json_decode() 即是为此存在;用 $_GET 的话空格便无法表示。

    5. 结束。至此,已经构造出了符合简单模板命令调用样式的表达式。

下面是以题目环境为基准的表达式替换过程:

    1. Hello, {\ %name% /}

    2. Hello, {\ '{{%n1%' /}

    3. Hello, {\ '{{'%n2%'' /}

    4. Hello, {\ '{{''\\%n3%''' /}

    5. Hello, {\ '{{''\\'%n4%'''' /}

    6. Hello, {\ '{{''\\''phpinfo(%''''' /} (加入省略的部分 ↓)

    7. Hello, {\phpinfo(% \nYour lucky number today: {\ get_lucky_number(%name%); /}

    8. Hello, {\phpinfo('-1'); /}

以及先行版 payload:

由此观察 phpinfo() 的各种信息,发现是 PHP 8.2 且 disable_functions 巨长,基本无法 getshell。

下面这个过滤也很烦人。题目环境中 hello.tpl 无自带 unsafe 参数,且无法通过 % % 替换被添加进去;最后那个正则更是丧心病狂,只有 f l a g 0 1 – / * 这寥寥无几的字符可以通行。

注意到按照题目的写法,除了函数,PHP 的原生类也是可以执行的;先用 GlobIterator 探探目录:

一下子就找到 flag 了。但如何读取它才是问题,无论 readfile() ; file_get_contents() 还是 SplFileObject 都需要提供完整的文件路径,而这个参数被正则控制得死死的。

在束手无策的同时也注意到这个正则采用了一种比较少见的写法 (...|[...])+ ,一般来说会写成 (...|[...]+),那这俩有什么区别?

还是涉及到 PHP7.0+ pcre.jit(默认开启)的一个设计缺陷Bug#70110):在进行 (A|B)+(A{1,2}B)* 这样的匹配时,仅需 1w 个左右的 AB 就可使 preg_match() 返回错误;不同于基本上需要 100w 个字符的 PREG_BACKTRACK_LIMIT_ERROR,返回的是 PREG_JIT_STACKLIMIT_ERROR,即在编译 JIT 时栈溢出(超过 PHP 默认值 32K)。原理大概可以认为是 JIT 在编译括号时需要反复进行压栈操作以回溯中间的“或”,成功匹配太多次后造成溢出。

那么对于题目环境的 /(flag|[^flag0-1\-\/\*])+/is,很简单,随意往参数前面扔 7k 个不合法字符即可让 preg_match() 返回 FALSE,绕过成功;且刚好不超过 8KB 的 GET 限制。

但到这里还没有结束,至此字符串长度超过了 4KB,作为路径是不合法的,自然也无法读取到文件。

此时只能另辟蹊径,注意到命令执行完后也只是把结果替换进模板字符串里,跟变量替换如出一辙,存在操纵空间;于是可以通过闭合前面的模板标识来新增一条含 unsafe 参数的简单命令执行语句。

提交的参数不能含分号,但函数执行后的结果可以,于是用 base64_decode() 之类的包装一下即可:(在前面添加一堆非法字符 = 也不会影响 base64_decode() 的结果)

至此,终于可以安心地获得本题的 flag 了,以下为 payload:

出题后话:字符串替换的利用可以很巧妙,本人尝试还原出了比较常见的一种类型。关于 preg_match 的漏洞点不过参数或返回值类型混淆,本来想结合点 PHP 8+ 的新特性,却迟迟没有找到合适的,只能从 Bugs 堆里拎出一个看起来比较鸡肋的来。说到 template,可是本题却与 template 一点关系都没有,相信屏幕前的你一定也是这么想的。

 

 


  • easy_pickle

(同时提供 PDF 版:writeup_easy_pickle.pdf

环境分析:不提供附件,可以发现是 flask 开启 debug 模式。

题目被设计成一个类似于闯关的模型,先顺着它的思路往下看。

一直点就能到达 challenge 1 处,从报错信息得到部分源代码:

限制了提交的长度字符集类型,最后进了 pickle.loads()判断返回值

先试几手,比如随便提交个特殊符号,得到 validate() 源代码:

发现 GET 过滤.. 等,而 POST 过滤了喜闻乐见的 R i o b 等,封锁了一些常见的简单漏洞。

首先尝试通过 challenge 1,分析题目默认提供的 payload 4930300a2e

发现仅需把返回值改为 True,也就是 b'I01\n.' ,提交 4930310a2e 即可。

到达 challenge 2 处,从报错信息得到部分源代码:

限制了提交的长度,字符集类型,最后同样进了 pickle.loads 并判断返回值。

分析题目默认提供的 payload 286456757365720a5667756573740a732e

发现仅需把 'guest' 改为 'admin',但同时注意到 i 会被 waf 拦截下来,使用 \u0069 绕过即可。

得到b'(dVuser\nVadm\\u0069n\ns.',提交286456757365720a5661646d5c75303036396e0a732e

到达 challenge 3 处,从报错信息得到部分源代码:

可以发现需要在 pickle 中引入 __main__.guidance 以绕过限制,题目默认提供的 payload 是常规的:

注意到 _ 会被拦截,先试着随意使用 c (GLOBAL) 字节指令爆出 RestrictedUnpickler() 的部分源代码:

其中 builtins 为白名单控制, __main__ 可以任意导入,且均经过 .lower() 处理。

也就是控制模块名为 maIn 就可以在不触发 waf 的前提下引入 __main__ ;变量 guIdance 同理。

得到 b'cmaIn\nguIdance\n.' ,即提交 payload 636d61496e0a67754964616e63650a2e

到达 challenge 4 处,从报错信息得到部分源代码:

前面都是判断 isascii(),而本次判断 notascii() ,并允许了 . 和小写字母。

同样的,先分析题目默认提供的 payload 8004892e

更简单了,直接 pickle.dumps() 构造或者查看 pickle 的源代码:

改为 b'\x80\x04\x88.' ,即提交 8004882e 即可。

然后会发现 challenge 结束了,没有 flag

可以在结束页面的源代码中发现 /static/hint.txt ,或者在 failed() 报错信息中发现 /static/ 路由

终于明白为什么 waf 要拦截 .. 了,就当前的限制而言,目录穿越是不可能的。

尝试综合一下所有功能:Flaskdebug mode文件读取pickle.loads;不知是否有这样一条路浮现出来:

pickle.loads() --> raw_file() (BYPASS WAF) --> debug pin --> RCE

虽然其中许多细节尚不明确,但这些正是接下来需要探索的方向。

一个问题,如何获得 raw_file() 的回显? 代码中没有任何显示出 pickle.loads() 返回值的部分;

注意到 debug mode 开启,而 failed() 正是用来报错的函数,改为调用 failed(raw_file()) 即可。

一个问题,pickle.loads() 如何执行函数?其中 R i o b NEWOBJ = b'\x81' 已被过滤;

注意到 NEWOBJ_EX = b'\x92' 未被过滤,可以仿照 NEWOBJ 的方法执行函数,观察其源代码:

根据 find_class()builtins 白名单 {'range','complex','set','frozenset','slice','filter','str','bytes','map','dict','list'},从众多的选项中慎重地选出了一个:

使用 map 而非 filter 因为前者能返回执行的结果,使用 frozenset 因为其能触发 __next__() 并调用函数。

最关键的问题,前三个 challenge 限制 isascii(),而第四个 challenge 限制 notascii() ,如何绕过?

很明显 NEWOBJ_EX 无法出现在前三个中,而仅用小写字母无法在第四个中构造出可利用的字符串,因为此时仅有 STACK_GLOBAL = b'\x93' 可以用来引入变量(使用 c 的话会不可避免地遇到大写字母),而被压入的字符串无法像 VS 字节指令一样绕过 waf。

为看清问题的全貌,随意使用一些非法的字节序列还原出 RestrictedUnpickler().loads() 的部分源代码:

注意到并不是每次都生成新的 pickle._Unpickler 实例,而是更改了某些必须的参数并复用了当前实例。

查看 pickle.py 源代码:

注意到 self.stack 在每次 load() 时被重新创建,而 self.memo 仅在实例化对象时被清空了一次

再看 /chall 路由的主要代码,发现四个 challenge 确实同时使用了 pickle = RestrictedUnpickler() 这一个实例,也就是说 self.memo 在这四个 challenge 中是会保留的,且不同 challenge 可以在同一请求内被按顺序依次执行(只要有 chall{id} 这个参数);于是利用 self.memo 传递数据,在前三个 challenge 中利用各种方法绕过 waf 创建非法字符串并存进 self.memo 中,在第四个 challenge 中取出以 NEWOBJ_EX 执行函数。

分析得出需要 builtins map frozenset main failed raw_file ../../filepath 这几个字符串,前两个 challenge 提交长度限制过紧,故在 challenge 3 中构造 BuIltIns frOzenset maIn faIled raw\\u005ffIle ../../filepath 并依次存入 self.memo ,最后不忘满足 challenge 3 的通关条件:

这里以获取 debug pin 需要读取的最长的文件名 ../../proc/sys/kernel/random/boot_id 为例,可以发现 150 的字符限制还是很吃紧的。采用的优化措施包括:map 完全合法,故放到 challenge 4 中构造;直接使用 c (GLOBAL) 字节指令引入后再放入 self.memo 会显著地超出允许的提交长度,故仅存储字符串;在没有转义的情况下,使用 V 字节指令引入字符串比 S 节省 1 字节;在有多个转义的情况下,使用 \\xCC + S 字节指令引入字符串比使用 \\u00CC + V 节省多个字节

同时注意到,作为 NEWOBJ_EX 参数的 **kwargs 无法使用非 ascii 字符构造,故还需要提前存储一个空 dict

而 challenge 4 就不需要这么紧张了:

http://web:8888/chall 处提交如上的 chall3={c3.hex()}&chall4={c4.hex()} 即可读取任意文件。

最后,仅需读取 /sys/class/net/eth0/address /proc/sys/kernel/random/boot_id /proc/self/cgroup 这三个文件,并使用默认值 'nobody' 'flask.app' 'Flask' '/usr/local/lib/python3.11/site-packages/flask/app.py' ,即可计算出 debug pin,完成 RCE

以下为获取 debug pin 的 payload:(至于之后的 RCE + /readflag 过程,就不需要赘述了吧?)

出题后话:某场比赛中一不小心非预期了 R i o b 的某道 pickle 题,这里算是一个加强版。刚开始的想法是弄一个需要综合各个部分来“前后配合”的解法,没想到 self.memo 刚好与它不谋而合,所以我常说不是它发现了 self.memo,而是 self.memo 找上了它。关于字符限制,刚开始只是随便打了个数 150,也没想到构造出来会卡得这么紧,那就顺其自然吧。至于大量重复出现的 Lord 什么的 God 什么的,其实是在搜迫真名言警句的时候偶然点进了 Bible 的链接,为了上下文统一就变成了这样;其实放点什么都行,只要不是空着。

 

 


说起本人正式入坑 CTF 的契机,其实也挺有趣的。其一是在平常绝对不会去的某食堂干完饭后,偶然间发现了被随意摆放在出口角落、已经沾灰了的招新看板;此时才第一次真切地认识到,啊,原来学校里还有这样一支队伍啊。这么说貌似有点不大好,但毕竟是在不同的校区。其实仔细想过去肯定能发现是有的,要找的话也不可能找不到,只是之前从来没有产生过这样的冲动;既然遇到了那就是缘分,记录下联系方式,做了几天迫真的心理准备,凭借以前乱搞留下的底子,顺利转正。其二是在某个普通的日子,学长们带我打 CTF 比赛,前一天可能是玩通宵了还是咋的,结束时晚上六点多有点困了,小憩一会准备接下来的 ACM 招新选拔。想着眯一会就没设闹钟,注意这是伏笔,然后一觉醒来发现还有 20 分钟结束,流汗黄豆,慌慌忙忙开机上号,最后的入队标准是 A 4 个题好像,前俩一遍过,第四调了一下也过,留给第三的时间已经不多了,一局定胜负。第一发好像 CE 了来着,搞得很尴尬;最后的结果相信各位也已经猜到了,那就是令人悔恨的 WA,很遗憾地 fail 了招新选拔。我将其称之为“缘分未到”,也就没有刻意地再去争取了;如果进了 ACM 集训,那将会消耗绝大多数的时间,CTF 这方面应该也就会稍微放放了吧。不过这么说倒是自己都有点不好意思,现在其实也就学长带着混混比赛,平时该干啥干啥;进了 ACM 可能会减少 CTF 的时间,但没进 ACM 结果留给 CTF 的时间好像也没有增加,原来这就是摸鱼生活,幸好当初没进 ACM 集训,缘,妙不可言。

好像跑得有点偏了,回到主题。毕竟是第一次尝试出题,尽可能地避免了鸡肋、钻牛角尖的情况,也不知道实际上有没有做到,但如果是自己在遇到这些情况时,经过一段时间的摸索和练习,还是比较有希望能给出预期解的。题一需要注意到 SELECT 返回二维数组与可能的原型链污染之间的关系,可能的歪路有尝试攻破只读的 mariadb,虽然都已经放只读了,还有前端的逻辑漏洞,虽然已经提示非漏洞点了,等等。题二需要有明确的思路,污染模板+原生类目录遍历+过滤绕过,其余的每一种方法都被封锁了,理论上是这样,可能会花上一些时间探索,要是死磕在一条歪路上就糟糕了。题三的迷惑性很强,但是亲切地给了 hint.txt,嗯,应该是没问题的,需要发现 loads() 与 self.memo 是解题的一大关键点,为此得触发各种不同的错误来尽可能地多爆出一点源代码,另外 150 的字符限制对于习惯于缩行的OIer们可能没什么难度,注意这里并不是特指,构造起来也是需要花费一点心思的。总之,不管怎么样,我是玩得很开心了,希望各位也能像我一样玩得开心。

 

 

发表回复

您的电子邮箱地址不会被公开。 必填项已用 * 标注