如何逆向Wyse终端的口令加密机制
瘦客户端变得越来越流行，因为它提供了一种实现虚拟化基础设施的方法。它通常是以桌面环境或者独立程序（比如，记事本/微软Office应用程序/浏览器）的形式出现的。
FreeBuf百科：瘦客户端与Wyse
瘦客户端（thin client） 是使用专业嵌入式处理器、小型本地DOM电子盘、精简版操作系统的基于PC工业标准设计的小型行业专用商用PC。 配置包含专业的低功耗、高运算功能的嵌入式处理器。不可移除地用于存储操作系统的本地闪存、以及本地系统内存、网络适配器、显卡和其它外设的标配输入/输出选件。瘦客户机没有可移除的部件，可以提供比普通PC更加安全可靠的使用环境，以及更低的功耗，更高的安全性。
Wyse 是全球大型企业和机构信赖的可扩展智能网络运算解决方案的头号供应商。 Wyse瘦客户端 是市场上广泛运用的瘦客户机品牌之一。
先不管这一技术的优点，今天我将讨论最近在一个特定设备上发现的一个弱点。它就是Wyse瘦客户端。
在公司网络中，通常能找到许多使用瘦客户端技术的产品。到目前为止，Wyse是遇到最多的，我们应该对下面的登录界面很熟悉：
Wyse瘦客户端使用的FTP服务器被设置为支持匿名认证。我们看看FTP服务器上的内容。
Wyse瘦客户端依赖于“wnos.ini”文件进行初始化，获得配置信息。当一个瘦客户端启动时，通常会发生下面的事情：
1、客户端通过DHCP配置基本的网络访问
2、客户端检查DHCP选项中的161/162，识别FTP服务器
3、客户端通过匿名认证从FTP服务器上获得wnos.ini文件
作为一个标准步骤，任何专家都会在配置文件中查找敏感信息。我们多次碰到，在各种形式的配置文件中发现了硬编码的域管理员的凭证。
下面是wnos.ini配置文件的样例。用户名和口令的值已被重点标注
;************************************************************* ;* * ;* This wnos.ini file was generated with the * ;* Configuration Generator 7.4.02 * ;* Copyright by Thomas Moellerbernd * ;* * ;* http://www.technicalhelp.de * ;* * ;************************************************************* ;************************************************************* ;* General 1 * ;************************************************************* AdminMode=yes Admin-Username=MEAFMNABMK Admin-Password=MEAFMNABMKFOMJFP Privilege=None HideSysInfo=yes HidePPP=yes EnableNetworkTest=yes ShowDisplaySettings=DDC-Only SuppressTaskbar=yes ;************************************************************* ;* Wireless / 802.1x * ;************************************************************* ~truncated for brevity~
一些东西引起我们的关注：
1、密码总是以相同的编码方式保存（大写字母）。
2、在这里，“Admin-Password”字符串中有一部分数据与“Admin-Username”重合
3、配置文件中提到了生成它的工具！我们能不能用这个工具逆向出密码呢？
一个简短的搜索发现了很多东西 ，在技术支持论坛上，网络管理员上传了他们的wnos.ini文件。奇怪的是，这些wnos.ini文件中大部分都包含了“Admin-Password”的值！
https://community.wyse.com/forum/archive/index.php/t-11964.html
https://communities.vmware.com/thread/217441?start=0&tstart=0
我们首先下载了配置文件中提到的配置文件生成器“Configuration Generator”。当导入了wnos.ini文件之后，我们立即注意到“Encrypted Admin Password”区域被填充上了值。
这个工具是与其它一些文件一起打包的，其中有一个名为‘CryptGui.exe’的win32二进制文件。
bundle32.exe
Configuration Generator.exe
CryptGui.exe
Interop.MSXML2.dll
Interop.Scripting.dll
rc.dll
readme.txt
sihp1000.dl
sihp1005.dl
sihp1018.dl
sihp1020.dl
sref.k
SysInfo.dll
使用命令行运行这个文件，输出了一些结果：
C:toolswyse>CryptGui.exe password Number of command line parameters = 1 password;NFBBMHBBMDAJNOBP;lFeuV/Q78Swvk
这个exe看起来是接收了输入，并且把它回显回来，而且还有2个不同的对password的编码，尤其是高亮的字符串，它与我们获取的wnos.ini文件中的字符串非常相似。
我们可以利用密码分析技术破解出密码，通过提供一些基本的字符串观察加密模式来实现。（实际上，已经有文章总结了这个方法，dschuetz写的 similar encoding technique ）
下面是一些基本样例的输出：
我们可以看到，一个字符用两个大写字母表示，而且好像每个位置上的字符的对应关系是静态的，字符串为“aaa”和“bbb”时我们可以看到XXYYXX的模式，但是在字符串为“bab”时，我们看到的字母却与我们预想的不一样。
这些让我们怀疑它使用了静态密钥，没有加盐，并且编码时使用了2个（或更多）字符来产生编码结果。
我稍微后退一步，看看configuration generator能不能用来解码或解密口令，我们把wnosi.ini文件加载到configuration generator中，并且附加上调试器：
希望我们能够通过欺骗这个工具令它泄露出一些秘密，终于，过了一会儿我们发现了隐藏在内存中的被编码的口令：
就在编码了的口令的右边，有一个看起来是明文的东西！我们立即奔向附近的Wyse瘦客户端，尝试在管理员登录界面上输入这个口令，成功了！：
还能怎样改进？
现在我们注意到两点：
我们能够断定，它使用了一个静态密钥或者算法来加密口令，而且可以轻易地逆向出明文口令
我们现在能够解码出口令，尽管过程稍微有点麻烦
要想整理并提出一个独立的解决方案，我们需要逆向出算法，有两个明显的办法：
1、密码分析
2、反汇编configuration Generator程序
逻辑上看，第二个应该是第一步。另外，我们再看一下CryptGui.exe程序。
这个程序使用C#编写，它被编译成字节码，在.NET虚拟机上运行。对我们有利的地方是，源代码和字节码之间有很强的关联性，比如，我们能够反编译它（就像对Java和Android程序一样）。
这看来好像不管用？虽然反编译成功了，但是不是我们想要的。实际上，它调用了外部的非.NET代码,它导入了SysInfo.dll，然后定义了一个对里面函数的直接映射，名为NFuseDecode，它有三个参数：
InBuffer – 密文缓冲区
length – 密文长度
OutBuffer – 明文缓冲区
这意味着，我们不能仅仅通过反编译.NET代码来得出加密逻辑，我们需要反汇编这个DLL，并跟踪指令的执行流程，了解它的机理。因此，我们使用IDA Pro加载并分析这个DLL。
IDA以图形的方式显示了系统调用的流程，如下图所示：
这个图被缩小了，我们看不清里面内容，只能看到流程，但是我们可以看出一些东西：
1、它是一个非常短的函数
2、它主要由两个循环构成，用红色和蓝色标注的部分
这两个循环引起了我们的兴趣，这两个需要单独地仔细查看，首先是第一个（红色部分）：
.text:10001AA0 loc_10001AA0: ; CODE XREF: NFuseDecode(x,x,x)+49j .text:10001AA0 mov dl, [eax] .text:10001AA2 sub dl, 1 .text:10001AA5 shl dl, 4 .text:10001AA8 add dl, [eax+1] .text:10001AAB add eax, 2 .text:10001AAE sub dl, 41h .text:10001AB1 mov [ecx], dl .text:10001AB3 add ecx, 1 .text:10001AB6 sub esi, 1 .text:10001AB9 jnz short loc_10001AA0 .text:10001ABB pop esi
对于不熟悉汇编的人，这些看起来就像是一堆随机字符，但实际上它很简单。我们将它翻译成C代码，看看它做了什么：
for (int i=0; i < length; i++) { a = src[i]; a -= 1; a <<= 4; a += src[i+1]; a -= 0x41 dst[i] = a; }
这是一个基本的base26解码，比如，它会把两个大写字母转换成一个字节的数据。我以字符ME为例说明这个过程：
1、取第一个字符M，它的十六进制是0x4d
2、给它减去1（=0x4c）
3、将之左移4位，会丢弃高半字节，将低半字节移至高半字节（=0xc0）
4、取第二个字符E，十六进制表示为0×45，将它与前面的值相加（=0×105）
5、减去0×41，a的十六进为0xc4
因此，第一个循环只是大写字母和二进制的转换，让我们看第二个循环（蓝色部分）：
.text:10001AD0 loc_10001AD0: ; CODE XREF: NFuseDecode(x,x,x)+76j .text:10001AD0 mov dl, [eax-1] .text:10001AD3 xor dl, [eax] .text:10001AD5 add ecx, 0FFFFh .text:10001ADB xor dl, 0A5h .text:10001ADE mov [eax], dl .text:10001AE0 sub eax, 1 .text:10001AE3 test cx, cx .text:10001AE6 ja short loc_10001AD0
它向后遍历整个编码的字符串，将每一个字节与前面的字节异或，然后与0xa5这个静态密钥异或，C代码：
for (i=length; i>=0; i–) { a=dst[i-1]; a^=dst[i]; a^=0xA5; dst[i]=a; }
用文本“bab”来试试：
加密后的口令：MHADME
base26解码后：0xc7 0×03 0xc4
第三个字符=0×03 XOR 0xc4 XOR 0xa5 = 0×62 (‘b’)
第二个字符=0xc7 XOR 0×03 XOR 0xa5 = 0×61 (‘a’)
第一个字符=0×00 XOR 0xc7 XOR 0xa5 = 0×62 (‘b’)
明文：bab
为了节省时间，我们写了一个简单的c程序，你可以在我们的github页面上找到 源代码 。
./pwdecode MEAANHBGMFABNGBI aardvark
最后的想法
把口令以可逆的形式存储是不明智的。我们用了不到一个小时就从wnos.ini文件中得到了明文口令，而且现在我们可以根据需要解码任何口令。
这个口令可以用来访问Wyse瘦客户端的管理面板：
这本身并不能给攻击者带来多大的好处，但是可以用它来修改Wyse瘦客户端的本地配置，执行原本阻止的操作。
一个更大隐患是密码重用，我们看到过许多客户在其它内部系统上重用了wnos.ini文件中保存的口令！使用这个文章提出的方法，攻击者可以利用wnos.ini文件在内部区域中立足。
我们没看到其它可选项，只能用默认的编码算法。Wyse瘦客户端好像不支持其它安全的口令保存形式，比如，哈希。
在这里，我们的建议非常普通： 确保wnos.ini文件中保存的口令不要在其它地方使用！
我们也建议你检查下默认的BIOS口令“Fireport”（大小写敏感）。
* 翻译自： pentestpartners ，转载请注明来自FreeBuf黑客与极客（FreeBuf.COM）
正文到此结束
热门推荐
相关文章
近期评论
-
666
-
文章和留言都翻到11页了 没有OOM
-
-
朋友，翻页到11页，及以后，会出现OOM，无法访问
-
-
-
-
版本号是多少，你可以下载哪个代码仓库，jdk选1.8 直接跑就行
-
-
Loading...
![[HBLOG]公众号](https://www.liuhaihua.cn/img/qrcode_gzh.jpg)
