UIUCTF2021 Tablet（iPadOS Forensics）

 

Tablet1

Red has been acting very sus lately… so I took a backup of their tablet to see if they are hiding something!
It looks like Red has been exfiltrating sensitive data bound for Mira HQ to their own private server. We need to access that server and contain the leak.

私钥

grep  -r "ssh" ./

搜索到webssh.db后，利用DB Browser打开db文件。

导出私钥为ssl.txt。

一开始以为还要去找密码，其实********这就是密码了。利用一下命令把openssl private key 解密一下。

ssh-keygen -p -N "" -m pem -f ssh.txt

得到rsa 密钥，我们现在可以去连接服务器了。

当然也可以直接用以下这条命令

ssh -p 42069 -i id_rsa red.cha1.uiuc.tf

在这里我使用xshell进行连接

一开始以为是ssh连接服务器，这个服务器肯定不会允许搞破坏，应该是连不上的。

sftp

提示我们利用sftp进行连接，我们修改连接方式，可以看到我们已经连接到服务器上了。

ls，查看当前目录下的文件和权限。

get，下载.bash_history文件

mv /srv/exfiltrated "/srv/..."

提示我们到/srv/...目录下。

发现一张图片，get下来，就是flag

uiuctf{upload_task_only_takes_9_seconds_0bf79b}

 

Tablet2

Wait… there are TWO impostors?! Red must have been in contact with the other impostor. See if you can find out what they are plotting.

bash_history

在/var/root/目录下找到了.bash_history,内容为以下部分

ls
exit
tar --version
exit

find ./ -iname *hammerandchisel* -type d 2>/dev/null
cd 0CE5D539-F72A-4C22-BADF-A02CE5A50D2E/
ls
cd Library/
ls
cd Caches/
ls
cd com.hammerandchisel.discord/
ls
rm -rf *
ls
cd ..
ls
ls
cd com.hammerandchisel.discord/
ls
exit
cd ../mobile/Containers/Data/Application/AA7DB282-D12B-4FB1-8DD2-F5FEF3E3198B/Library/Application\ Support/
rm webssh.db 
exit

需要关注的为以下两个命令，第二个命令是我们刚刚找到的webssh.db，

find ./ -iname *hammerandchisel* -type d 2>/dev/null

cd com.hammerandchisel.discord/
ls
rm -rf *

cd com.hammerandchisel.discord/
ls

cd ../mobile/Containers/Data/Application/AA7DB282-D12B-4FB1-8DD2-F5FEF3E3198B/Library/Application\ Support/
rm webssh.db

find

通过google得到这是discorder，我们考虑题目描述说的接触为discorder。

find ./ -iname *hammerandchisel*

找到文件****.plist

我们在这里看到了BlueAmogus，猜测为碰头的第二的人。但是我没有证据。

ktx

我们在这个文件夹找到了很多的ktx文件，为什们bash中需要删除它们呢？我们尝试着去打开这些文件。

这是一个压缩过的纹理图片，我们在windows下需要对应的工具转换该文件，或者在mac下可以直接查看ktx文件。

ios_ktx2png.exe *****.ktx

KTX 纹理压缩 | Egret Engine

从这张图，我们得到线索，一是encrypted note，二是password。

Cache.db

我们继续跟进之前的bash_history，找到对应的文件夹

打开Cache.db文件，慢慢看信息，发现了之前图片中被黑色覆盖的密码以及之前没看全的消息。

The password is ||su5Syb@k4||su5Syb@k4White is onto me... they kept calling me out last meetingI'll deal with them, you just make sure this next sabotage goes to planI sent you an encrypted note with all the details

那么现在，我们只需要去找到Blue发送给Red的note，并进行解密即可。那么note在哪里找呢？我也无法猜测到。而当我使用如下命令时，我看到了一个很符合的oneNote

grep -r "note" ./

在对应的文件夹中我们可以知道两个数据库文件。

我们可以在Records.db中发现recordData，导出为文件后找到了EncryptionInfo

接下来就该思考如何使用该密钥进行解密。

无法解密，当然，我们是找错了note文本。最后我们通过搜索encrypt找到了这个文件夹，可以看到EndToEndEncryption大概率就是出题人设置的文件夹。这是端到端加密，很多文件夹都有这样的一个子文件夹，并不是出题人的设置。

我们通过备忘录来打开里面的com.apple.notes.analytics.plist文件。但是似乎不需要密码。

说明我们找到的并不是最后真正加密的文件。我们返回上级目录。

在这里找到了一个mobilenotes.plist，可惜也不是这个。我们继续返回上级目录

NoteStore.sqlite

那么最后我们该如何去寻找加密的note呢？以下命令就可以找到对应的note存储的数据库。然后我们就需要利用密码去解密。

sudo find ./ -type f -name NoteStore.sqlitesudo find ./ -type f -name NoteStore.db

在github上面找到了一个ruby的项目，可以对已知密码的note可以进行解密。

apple_cloud_note_parser

在安装时，最可能出现的问题是在openssl上面。

https://stackoverflow.com/questions/66376203/failed-to-build-gem-native-extension-when-installing-openssl

log_info "Upgrading and linking OpenSSL ..."  brew install openssl  brew link openssl --force

得到报错信息后，把解决方案进行执行即可顺利安装apple_cloud_note_parser

echo "su5Syb@k4" > password.txtruby notes_cloud_ripper.rb -f NoteStore.sqlite -w password.txt

tips

以下为代码执行流程

generate_key_encrypting_key

aes_key_unwrap

本文所用文件已分享
链接: https://pan.baidu.com/s/1VLg805GD-eTHzEPLdGDAZA 提取码: alh5