misc周报02

【为者常成,行者常至。 ——《晏子春秋》】

本周流量分析专题练习

(源自NSSCTF的流量分析题)

题目:[陇剑杯 2021]webshell

进行追踪流,在第六个流中找到登录账号密码:

Admin123!@#

题目:[陇剑杯 2021]jwt系列(问1——问6)

问1:

追踪HTTP流,发现token

base64解码后,typ=jwt

(题目是jwt 当然是jwt认证方式……)

问2:

分析:JWT 由三部分组成: Header 头部、 Payload 负载 和 Signature 签名,它是一个很长的字符串,中间用点(.)隔开。客户端收到服务器返回的 JWT,可以储存在 Cookie 里面,也可以储存在 localStorage。
所以只要找到jwt解密即可。

通过分析数据包发现有个exec的命令执行成功,查看cookie

进行解码:

解码后id为10087,username为admin

问3:

image-20250306183700211

http contains “whoami” 命令查找http协议中包含whoami的流量包
查看http流中的回显,得到权限信息

root权限

问4:

过滤“POST”数据包,一个一个流分析

发现通过echo将base64加密的内容写进了文件内:

尝试解密查看,确实为恶意代码:

image-20250306185308193

所以文件名称为1.c

问5:

要找到so文件,使用http contains “.so”过滤指定字符串:

在最后一个数据包中找到文件

问6:

因为给的是黑客攻击流量,所有http的请求方法应该为“POST”,且Liunx系统下配置文件放在etc目录下,故筛选代码如下:http.request.method==“POST”&&http contains “etc”

echo “auth optional looter.so”>>/etc/pam.d/common-auth

意为:向/etc/pam.d/common-auth文件追加一行内容,内容为auth optional looter.so,故文件路径为/etc/pam.d/common-auth

本周取证专题练习(NSSCTF)

(源自NSSCTF的取证题)


题目:[蓝帽杯 2022 初赛]计算机取证_3

题目:

使用passware结合内存找BitLocker密码(太好用了)

用FTk Imager挂载解密后的镜像:

根据题目信息,flag应该在pptx或docx中间:

使用给的密码本进行字典爆破:

拿到ppt的密码,打开后,获得flag

1
flag{b27867b66866866686866883bb43536}

buuCTF misc部分题目记录


题目:[安洵杯 2019]吹着贝斯扫二维码

打开题目,里面是一堆文件和一个压缩包。

分析文件,发现都是jpg图片

因此需要给每个文件添加后缀名:

使用python脚本:

1
2
3
4
5
6
7
8
9
10
# coding=utf-8
import os

#将无后缀的文件加上.jpg
dir_list = os.listdir('C:/Users/31715/Desktop/tt')
#print(dir_list)
for file in dir_list:
if '.' not in file:
# print(file)
os.rename(file, file+'.jpg')

得到二维码碎片,我们需要将其拼装起来:

扫描二维码:

base系列,85->64->85->13->16->32加密

这里指的应该是压缩包里面的内容:

倒过来进行解密:

strings:

GNATOMJVIQZUKNJXGRCTGNRTGI3EMNZTGNBTKRJWGI2UIMRRGNBDEQZWGI3DKMSFGNCDMRJTII3TMNBQGM4TERRTGEZTOMRXGQYDGOBWGI2DCNBY

base32_decode:

3A715D3E574E36326F733C5E625D213B2C62652E3D6E3B7640392F3137274038624148

base16_decode:

:q]>WN62os<^b]!;,be.=n;v@9/17’@8bAH

Rot13_decode:

:d]>JA62bf<^o]!;,or.=a;i@9/17’@8oNU

base85_decode:

PCtvdWU4VFJnQUByYy4mK1lraTA=

base64_decode:

<+oue8TRgA@rc.&+Yki0

base85_decode:

ThisIsSecret!233

解压一下,flag{Qr_Is_MeAn1nGfuL}

题目:从娃娃抓起

根据题目描述,两行字符分别是两种不同的汉字编码。

经过分析,第一行为电报码:

解码后为人工智能

第二行是五笔编码:

解码为也要从娃娃抓起

将其链接在一起,按照题目要求求小写MD5:

得到flag!

题目:弱口令

打开题目,发现压缩包里面有隐藏信息:

复制到sublime,看到隐藏信息(这一步看了WP,没想到)

这应该就是压缩包的密码!

尝试解压:

里面是一张图片。

分析,lsb隐写。

题目:[GUET-CTF2019]zips

压缩包系列解密。

第一个压缩包,没有提示信息,直接暴力破解:

第二个压缩包,发现flag.zip可以解压出来,但是setup.sh不能解压出来,setup.sh显示压缩文件头部数据已经损坏

这里很有可能存在zip伪加密。那现在我想的是先将它拿到kali中binwalk检测一下。

两个zip,一个是flag.zip而一个是装的是setup.sh;那很可能是flag.zip没有被加密,而setup.sh对应的那个zip被伪加密了所以才导致无法直接把setup.sh解压缩出来。此时可以考虑通过binwalk直接将它们分离,可能可以直接得到setup.sh文件。

伪加密修复后,再进行解压,这时候可以查看setup.sh的内容:

1
2
3
4
5
6
7
8
#!/bin/bash: 这是一个Shebang行,指定了该脚本应使用/bin/bash解释器执行。它是Unix/Linux系统中可执行脚本的标准起始行。

zip -e --password=: 这部分命令调用了zip程序来创建或更新一个ZIP归档文件,并使用-e选项指明需要对存档中的文件进行加密。

python -c "print(__import__('time').time())": 这里嵌入了一个Python命令,用于执行一段Python代码。具体来说,它导入了time模块,并调用其time()函数来获取当前的Unix时间戳。这个时间值将作为接下来操作的密码。

flag.zip flag: 表示要创建或更新的ZIP文件名为flag.zip,并且要将当前目录下的一个名为flag的文件添加到此ZIP文件中。由于前面设置了-e和--password,所以在添加过程中会对flag文件进行加密,并使用由Python计算出的时间戳作为加密密码。

这段脚本是用Bash编写的,其主要功能是使用Python计算当前时间(以Unix时间戳形式表示,即从1970年1月1日00:00:00 UTC以来的秒数)并以此时间为密码来加密一个名为flag.zip的ZIP文件,其中包含一个名为flag的文件。

16:40:15,那么可以通过以下python代码获得此时的unix时间戳:

1
2
3
4
5
6
import time
t_str = '2019-5-17 16:40:15'
t_tuple = time.strptime(t_str, "%Y-%m-%d %H:%M:%S")
t_unix = time.mktime(t_tuple)
print(t_unix)
# 输出结果:1558082415.0

通过上述我们得到了其创建flag.zip的时候对应时间的unix时间戳,但这不代表我们就获得了密码,现在目光需要重新回到setup.sh文件,在kali中执行其中的python代码,这是因为作者在创建flag.zip文件的时候一定是在linux中执行的setup.sh脚本:

而python2和python3的时间戳格式是不一样的(这里是python2,为什么呢?因为看了WP……🙄)

引用一下其中的内容:

1
2
3
4
可以看到通过python2执行后,获得的unix时间戳的小数位数都是两位,那么到底是python2还是python3呢,这里我觉得就只有凭经验判断了,在以前写的工具或者exp之类的东西大都是通过python2写的,所以这里可以优先考虑python2,python2不行再换python3。
————————————————

原文链接:https://blog.csdn.net/weixin_62248541/article/details/142741438

截取其中的print(__import__('time').time())python代码,在Python2环境下运行,得到时间戳格式

知道格式后,就可以利用掩码爆破爆破出密码:

1
2
3
可以以1558080000.00为开始,以1558089999.99为结束来进行掩码爆破,这样可以极大提高密码破解的效率。至于我怎么得到这个范围了,因为有误差所以只能靠猜了,因为以上两个时间分别对应的是2019.5.17 16.40.00和2019.5.17 17.00.00,它们对应的unix时间戳前半部分都是155808,所以我就让前半部分不变,然后对后面进行掩码爆破。
——————————————
原文链接:https://blog.csdn.net/weixin_62248541/article/details/142741438

解压拿到flag!

学习总结:


本周主要做题为主,misc的大部分题目在buu上面做题,取证和流量分析则是通过NSSCTF进行查找并做题。

计划是通过做题来找寻涉及的知识点,而后对其进行学习,主要以流量分析和取证为主。目前感觉流量分析技能十分欠缺,web知识很缺乏,做题离不开WP。计划结合对WEB的学习,一点点掌握流量分析技巧,下周准备大批量做流量题。

然后就是,基础的misc,包括各种的隐写什么的,感觉还应该多做题,熟练度不够。

👀👀

知识点总结:

JWT

组成:

JWT由三部分组成,通常这三部分通过点(.)连接,格式为xxxx.yyyy.zzzz。

Header(头部):通常包含两部分信息:token的类型(例如JWT)和所使用的签名算法(如HMAC SHA256或RSA)。

Payload(负载):包含声明(claims),这些声明是关于实体(通常是用户)和其他数据的声明。声明有三种类型:

    Registered claims:预定义的字段,如iss(发行者)、exp(过期时间)、sub(主题)等。

    Public claims:公共的claims,可以随意定义,但为了避免冲突,应该使用IANA JSON Web Token URL。

    Private claims:私有的claims,用于在同意使用JWT的各方之间共享信息。

Signature(签名):用于验证该token自签发后未被更改。它使用header中指定的算法和服务器端的密钥(secret key或公钥)与header、payload一起计算得出。

工作原理:

生成Token:当用户登录时,服务器使用用户的凭据生成一个JWT。这个过程中,服务器会创建一个payload,其中包括用户的ID和其他相关信息,然后用一个密钥(密钥可以是共享的secret key或私钥)和一个特定的算法对头部和负载进行签名。

传输Token:生成的JWT被发送给客户端,通常是通过HTTP响应头中的Authorization字段。

验证Token:每次客户端请求需要验证用户身份的资源时,它都会在请求中携带这个JWT。服务器接收到请求后,会验证JWT的签名是否有效,以及token是否未过期等。如果验证通过,服务器就可以信任该token中的信息,如用户的身份和权限等。

安全性:

JWT的安全性依赖于其签名机制。只要密钥保持安全,JWT就可以被认为是安全的。然而,需要注意的是,虽然JWT可以被签名以防止篡改,但不应该在JWT的payload中存储敏感信息,因为任何人都可以解码查看payload中的内容(除非使用加密手段)。

使用场景:

JWT常用于API的身份验证和授权中,因为它可以跨域传输且易于在不同的系统间共享身份信息。