原文地址:TouchEn nxKey: The keylogging anti-keylogger solution
我一周前写过关于韩国的强制性所谓安全应用程序。我的旅程始于 RaonSecure 的 TouchEn nxKey,它引起了我的注意,因为相应的浏览器扩展程序拥有超过 1000 万用户——Chrome 网上应用店将显示的最高数量。实际用户数量可能要高得多,韩国几乎所有计算机上都安装了该软件。
这并不是因为人们非常喜欢它:他们完全讨厌它,导致平均评分为 1.3 分(满分 5 星),并且有很多人呼吁废除它。但是,如果您想在韩国进行网上银行之类的操作,则需要使用它。
推动安装该软件的银行声称它提高了安全性。人们称其为“恶意软件”和“键盘记录程序”。我花了一些时间分析产品的内部运作,并确定后者更接近事实。该应用程序确实在设计上包含了关键的日志记录功能,但未能充分限制对其的访问。此外,各种错误的范围从简单的拒绝服务到促进远程代码执行。我总共报告了产品中的七个安全漏洞。
在我大致介绍了韩国的情况后,人们开始在各种韩国网站上讨论我的文章。一条评论特别提供了我所缺少的重要信息:2005 年关于韩国外汇银行黑客事件的两则新闻报道[1] [2]。这些只是技术细节,但让我试着解释一下我是如何理解这一点的。
这在 2005 年的韩国显然是一件大事。一个网络犯罪团伙通过远程访问木马设法从人们的银行账户中窃取了 5000 万韩元(当时约合 50,000 美元) 。这样,他们不仅获得了用户的登录凭据,还获得了安全卡中的信息。据我所知,这张安全卡类似于索引 TAN,后者是 2012 年在欧盟废除的第二因素身份验证方法,其确切原因是容易被银行木马破坏。
用户的计算机是如何感染这个恶意应用程序的?从描述来看,这听起来像是使用浏览器访问恶意网站时的路过式下载,很可能是浏览器漏洞被利用了。但是,也有可能用户被诱骗安装了该应用程序。有问题的浏览器没有命名,但肯定是 Internet Explorer,因为韩国此时没有使用任何其他浏览器。
现在新闻强调用户没有丢失或放弃他们的网上银行凭证,他们没有做错任何事。网上银行的完整性普遍受到质疑,银行因没有实施足够的安全预防措施而受到批评。
2005 年在其他国家也有很多这样的故事。虽然我不能说这个问题已经完全消除,但今天它已经不那么普遍了。一方面,网络浏览器变得更加安全。另一方面,银行改善了第二个因素。至少在欧洲,您通常需要第二台设备来确认交易。并且您在确认时会看到交易详情,因此您不会不小心确认转账给恶意行为者。
韩国选择了不同的路线,公愤要求速效。第二个新闻报道指出了罪魁祸首:安全应用程序本可以阻止攻击,但它的使用不是强制性的。银行遵守。它承诺提供“反黑客”应用程序,并强制所有用户使用它。
所以我能在 2006/2007 年左右找到第一次提到 TouchEn Key 可能不是巧合。当您将数据输入网页时,该应用程序声称会保护您的敏感数据。最终,开发了 TouchEn nxKey 以支持非 Microsoft 浏览器,这就是我研究的那个。
TouchEn nxKey 上的所有公共资源都表明,它以某种方式旨在通过加密键盘输入来对抗键盘记录器。这是我能找到的所有技术信息。所以我不得不自己想办法。
依赖 TouchEn nxKey 的网站运行 nxKey SDK,它由两部分组成:一堆在网站上运行的 JavaScript 代码和一些服务器端代码。下面是它的工作原理:
所以理论是:试图记录输入该网站的数据的键盘记录器只会看到加密数据。它可以看到网站使用的公钥,但不会有相应的私钥。所以没办法解密,密码是安全的。
是的,这是一个非常好的理论。
网站如何知道计算机上安装了特定的应用程序?它如何与之通信?
似乎这里正在发生范式转变。最初,TouchEn nxKey 需要安装其浏览器扩展。该浏览器扩展使用本机消息将请求从网站转发到应用程序。并将响应发送回网页。
然而,使用浏览器扩展作为中介不再是最先进的技术。目前的做法是网站使用WebSockets API直接与应用程序通信。不再需要浏览器扩展。
显示网站 busanbank.co.kr 通过 touchenex_nativecall() 与 TouchEn 浏览器扩展通信。 该扩展反过来通过本机消息与应用程序 CrossEXChrome 通信。 另一方面,网站 citibank.co.kr 通过 127.0.0.1:34581 上的 WebSocket 直接与应用程序 CrossEXService 通信。
我不确定这种范式转变究竟是从什么时候开始的,但还远未完成。虽然韩国花旗银行等一些网站专门使用新的 WebSocket 方法,但釜山银行等其他网站仍在运行完全依赖于浏览器扩展的旧代码。
这不仅仅意味着用户仍然需要安装浏览器扩展。它还解释了尽管安装了软件但仍未被识别的频繁抱怨。这些用户安装了不支持 WebSocket 通信的旧版本软件。没有自动更新。由于一些银行仍在提供这些旧版本的下载,这是我最初犯的一个错误。
TouchEn 浏览器扩展非常小,它的功能也很少。这里应该很难做错。然而,通过它的代码,我们看到这样的注释:
result = JSON.parse(result);
var cbfunction = result.callback;
var reply = JSON.stringify(result.reply);
var script_str = cbfunction + "(" + reply + ");";
//eval(script_str);
if(typeof window[cbfunction] == 'function')
{
windowcbfunction;
}
所以有人设计了一种非常糟糕(意思是:实际上很危险)的做事方式。然后他们要么意识到可以不用eval()
,要么有人向他们指出。然而,他们并没有删除错误的代码,而是保留了它以防万一。坦率地说,对我来说,这表明对 JavaScript、安全性和版本控制的掌握非常糟糕。也许只有我一个人,但我不会让这个人在无人监督的情况下为安全产品编写代码。
无论哪种方式,危险eval()
调用都已从浏览器扩展中清除。在银行网站使用的 nxKey SDK 的 JavaScript 部分并没有那么多,但到目前为止这些都不是问题。尽管如此,由于代码质量如此糟糕,肯定会出现更多问题。
而我在回调机制中发现了这样一个问题。网站可以向应用程序发送setcallback
请求以注册某些事件。当此类事件发生时,应用程序将指示扩展程序调用页面上已注册的回调函数。本质上,可以按名称调用页面上的任何全局函数。
那么恶意网页是否可以为其他网页注册回调?有两个障碍:
id="setcallback"
.第一个障碍意味着主要只能攻击使用 nxKey SDK 的网站。当通过浏览器扩展进行通信时,这些将创建必要的元素。通过 WebSockets 的通信不会创建此元素,这意味着使用较新的 nxKey SDK 的网站不会受到影响。
第二个障碍似乎意味着只能攻击当前选项卡中加载的页面,例如框架中加载的页面。除非可以诱骗 nxKey 应用程序tabid
在其响应中设置错误的值。
结果出奇地容易。当应用程序使用适当的 JSON 解析器来处理传入数据时,响应是通过调用sprintf_s()生成的。不执行转义。因此,操纵一些响应属性并为其添加引号允许注入任意 JSON 属性。
touchenex_nativecall({
…
id: 'something","x":"y'
…
});
该id
属性将被复制到应用程序的响应中,这意味着响应突然获得一个名为x
. 此漏洞允许将任何值tabid
注入到响应中。
恶意页面如何知道银行选项卡的 ID?它可以使用自己的选项卡 ID(TouchEn 扩展有帮助地公开)并尝试猜测其他选项卡 ID。或者它可以简单地将此值留空。扩展在这种情况下很有用:
tabid = response.response.tabid;
if (tabid == "")
{
chrome.tabs.query({active: true, currentWindow: true}, function(tabs) {
chrome.tabs.sendMessage(tabs[0].id, response, function(res) {});
});
}
因此,如果该tabid
值为空,它将把消息传递到当前活动的选项卡。
这意味着一种可能的攻击看起来像这样:
id="setcallback"
。setcallback
覆盖 JSON 响应属性。"tabid":""``"reply":"malicious payload"
对回调的第一次调用立即发生。因此,将在银行网站中调用回调函数,并将reply
属性中的恶意负载作为参数。
我们就快到了。一个可能的回调函数可能是eval
,但还有最后一个障碍:TouchEn 在将属性提供给回调之前传递该reply
属性。JSON.stringify()
所以我们实际上得到eval("\"malicious payload\"")
了并且这没有做任何事情。
另一方面,也许目标页面有 jQuery?调用$('"
将产生预期的结果:"')
gbank.busanbank.co.kr 说:嗨,_this_is_JavaScript_code_running_on_busanbank.co.kr
是否期望 jQuery 攻击成功作弊?不完全是,使用 TouchEn nxKey 的网站很可能也会使用 TouchEn Transkey(一种屏幕键盘),而这个网站依赖于 jQuery。总而言之,所有韩国银行网站似乎都严重依赖 jQuery,这是一个坏主意。
但是update_callback
,nxKey SDK 的指定回调也可以在传递 JSON 字符串化数据时被滥用以运行任意 JavaScript 代码。调用update_callback('{"FaqMove":"javascript:alert(\'Hi, this is JavaScript code running on \'+document.domain)"}')
将尝试重定向到javascript:
链接并运行任意代码作为副作用:
gbank.busanbank.co.kr 说:嗨,这是在 busanbank.co.kr 上运行的 JavaScript 代码
因此,这种攻击允许恶意网站破坏任何依赖 TouchEn 扩展的网站。并且韩国银行强制用户安装的“安全”应用程序中没有任何一个可以检测或阻止这种攻击。
当我开始测试时,Chrome 网上应用店中有两个 TouchEn 扩展。不太受欢迎但基本相同的扩展已被删除。
然而,这并不是故事的结局。我发现了另外三个几乎相同的扩展:INISAFE 的 CrossWeb EX 和 Smart Manager EX,以及 iniLINE 的 CrossWarpEX。CrossWeb EX 是其中最受欢迎的,目前拥有超过 400 万用户。这些扩展同样使网站容易受到攻击。
我的第一个想法是 RaonSecure 和 INISAFE 属于同一个公司集团。情况似乎并非如此。
但是后来我看到了iniLINE软件开发公司的这个页面:
带有 Initech 和 RaonSecure 徽标等的网页。
这将 Initech 和 RaonSecure 列为合作伙伴,因此 iniLINE 似乎是这些有问题的浏览器扩展的开发者。另一个有趣的细节:顶部“主要客户”行的第一个条目是国防部。我只希望他们的防御工作能产生比其他合作伙伴得到的更好的代码……
现在假设有一个恶意网站。假设这个网站告诉 TouchEn nxKey:“你好,用户现在在密码字段上,我想要他们输入的数据。” 那个网站会得到所有的键盘输入吗?
是的,它会!它会获取用户键入的任何内容,而不管当前哪个浏览器选项卡处于活动状态或者浏览器本身是否处于活动状态。nxKey 应用程序只是遵从请求,此时不会检查它是否有意义。事实上,它甚至会向网站提供在用户访问控制提示中输入的管理员密码。
但肯定有障碍?是的,有。首先,这样的网站需要有效的许可证。get_versions
在使用任何应用程序功能之前,它需要在调用中传达该许可证:
socket.send(JSON.stringify({
"tabid": "whatever",
"init": "get_versions",
"m": "nxkey",
"origin": "https://www.example.com",
"lic": "eyJ2ZXJzaW9uIjoiMS4wIiwiaXNzdWVfZGF0ZSI6IjIwMzAwMTAxMTIwMDAwIiwicHJvdG9jb2xfbmFtZSI6InRvdWNoZW5leCIsInV1aWQiOiIwMTIzNDU2Nzg5YWJjZGVmIiwibGljZW5zZSI6IldlMkVtUDZjajhOUVIvTk81L3VNQXRVd0EwQzB1RXFzRnRsTVQ1Y29FVkJpSTlYdXZCL1VCVVlHWlY2MVBGdnYvVUJlb1N6ZitSY285Q1d6UUZWSFlCcXhOcGxiZDI3Z2d0bFJNOUhETzdzPSJ9"
}));
此特定许可证仅对www.example.com
. 所以它只能被www.example.com
网站使用。或任何其他自称是www.example.com
.
看到origin
上面代码中的那个属性了吗?是的,TouchEn nxKey 实际上相信这一点,而不是查看Origin
HTTP 标头。因此,从某些合法使用 nxKey 的网站解除许可证并声称是该网站是微不足道的。甚至没有必要创建伪造的许可证。
另一个障碍:恶意网站收到的数据不会被加密吗?如何解密?应该可以使用不同的公钥,一个私钥已知的公钥。然后只需要知道算法,然后解密数据就可以了。
除了:这些都不是必需的。如果 TouchEn nxKey 根本没有收到任何公钥,它只会放弃加密!然后网站将以明文形式接收键盘输入。
看,我的概念验证页面(所有 HTML 样板不到 3 kB):
网页截图:嘿,这个页面知道你在其他应用程序中输入什么! 输入任何应用程序并观察此处出现的文本:我正在将此输入到 UAC 提示符中
还有第三个障碍,可以大大降低此漏洞的严重性:恶意网页拦截的键盘输入不再到达其目的地。当用户开始输入密码时,他们肯定会产生怀疑,但文本字段中什么也没有出现。我对 nxKey 应用程序的分析表明它只能以这种方式工作:键盘输入到达网页或其实际目标,但绝不会同时到达。
我们已经确定,编写该产品的 JavaScript 代码的人并不是很精通。但也许那是因为他们所有的专家都有 C++ 背景?我们之前已经看到过这一点,开发人员试图尽快离开 JavaScript 并将所有任务委托给 C++ 代码。
遗憾的是,这不是我可以证实的怀疑。与二进制代码相比,我更习惯于分析 JavaScript,但应用程序本身似乎同样充满了问题。事实上,它主要使用 C 而不是 C++ 的典型方法。这里有很多手动内存管理。
我已经提到了他们对sprintf_s()
. sprintf_s()
关于or等函数的一个有趣事实strcpy_s()
:虽然这些是不会溢出缓冲区的sprintf()
or函数的“内存安全”版本,但使用起来仍然很棘手。strcpy()
如果您未能为它们提供足够大的缓冲区,它们将调用无效参数处理程序。默认情况下,这会使应用程序崩溃。
猜猜看:nxKey 应用程序几乎从不确保缓冲区足够大。而且它也不会改变默认行为。因此,在许多情况下,向它发送过大的值会使应用程序崩溃。崩溃比缓冲区溢出好,但崩溃的应用程序无法再完成其工作。典型结果:您的网上银行登录表单似乎工作正常,但它现在以明文形式接收您的密码。当提交表单时出现错误消息时,您只会注意到有问题。此漏洞允许拒绝服务攻击。
另一个例子:在所有 JSON 解析器中,nxKey 应用程序的开发人员选择了一个用 C 编写的解析器。不仅如此,他们还采用了 2014 年 1 月以来的随机存储库状态,并且从不更新它。2014年6 月修复的空指针取消引用?是的,还在。因此,向]
应用程序发送(一个右方括号)而不是 JSON 数据足以使其崩溃。另一个允许拒绝服务攻击的漏洞。
那个 WebSockets 服务器网站连接到?它使用 OpenSSL。哪个OpenSSL?实际上,OpenSSL 1.0.2c。是的,我几乎能听到在场所有安保人员的集体感叹。OpenSSL 1.0.2c 已有七年历史。事实上,对 1.0.2 分支的支持已于三年前结束:2020 年 1 月 1 日。这里的最后一个版本是 OpenSSL 1.0.2u,这意味着还有 18 个版本修复了错误和安全问题。所有修复都没有进入 nxKey 应用程序。
让我们看看比崩溃更有趣的事情。上面提到的应用license是base64编码的数据。应用程序需要对其进行解码。解码器函数如下所示:
size_t base64_decode(char *input, size_t input_len, char **result)
{
size_t result_len = input_len / 4 * 3;
if (str[input_len - 1] == '=')
result_len--;
if (str[input_len - 2] == '=')
result_len--;
*result = malloc(result_len + 1);
// Decoding input in series of 4 characters here
}
我不确定这个功能来自哪里。它与 CycloneCRYPTO 库的 base64 解码器有明显的相似之处。但是 CycloneCRYPTO 将结果写入预先分配的缓冲区。因此,缓冲区分配逻辑可能是 nxKey 开发人员自己添加的。
而且这种逻辑是有缺陷的。它清楚地假设input_len
是四的倍数。但是对于像abcd==
它这样的输入,它的计算将导致分配一个 2 字节的缓冲区,尽管实际输出是 3 个字节大。
单字节堆溢出是否可以利用?是的,正如这篇零项目博客文章或Javier Jimenez 的这篇文章所解释的那样。然而,编写这样的 exploit 超出了我的技能水平。
相反,我的概念证明页面只是发送了 nxKey 应用程序随机生成的许可证字符串。这足以在几秒钟内使应用程序崩溃。连接调试器显示内存损坏的明显证据:应用程序崩溃是因为它试图使用伪造的内存位置读取或写入数据。在某些情况下,这些内存位置来自我网站提供的数据。很明显,具有足够技能和奉献精神的人可能会滥用该漏洞进行远程代码执行。
现代操作系统具有使像这样的缓冲区溢出更难转化为代码执行漏洞的机制。但这些机制只有在实际使用时才有用。然而,nxKey 开发人员在应用程序加载的两个 DLL 上关闭了地址空间布局随机化,在四个 DLL 上关闭了数据执行保护。
到目前为止,这都是关于基于网络的攻击。但是,恶意软件应用程序已经将其管理到系统中并正在寻找方法来扩展其权限的情况又如何呢?对于旨在帮助打击此类恶意软件的应用程序,TouchEn nxKey 在保持其自身功能方面的表现出奇地糟糕。
例如,CKAgentNXE.exe
每当 nxKey 拦截键盘输入时,助手应用程序就会启动。其目的:当 nxKey 不想处理某个密钥时,确保将其传递给正确的目标应用程序。主应用程序使用的库中的逻辑TKAppm.dll
大致如下所示:
if (IsAdmin())
keybd_event(virtualKey, scanCode, flags, extraInfo);
else
{
AgentConnector connector;
// An attempt to open the helper’s IPC objects
connector.connect();
if (!connector.connected)
{
// Application isn’t running, start it now
RunApplication("CKAgentNXE.exe");
while (!connector.connected)
{
Sleep(10);
connector.connect();
}
}
// Some IPC dance involving a mutex, shared memory and events
connector.sendData(2, virtualKey, scanCode, flags, extraInfo);
}
由于 nxKey 应用程序以用户权限运行,它将回退到CKAgentNXE.exe
在每个合理的设置中运行。该辅助应用程序在收到命令代码 2 后将调用SendInput()。
我花了一段时间才明白采用这种方法的原因可能是什么。毕竟,nxKey 应用程序和CKAgentNXE.exe
都在相同的权限级别上运行。为什么不直接打电话SendInput()
?为什么这种间接是必要的?
然而,我注意到CKAgentNXE.exe
它为其 IPC 对象设置了一个安全描述符,以允许从完整性级别为低的进程进行访问。而且我还注意到安装程序在下面创建注册表项HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Internet Explorer\Low Rights\ElevationPolicy
以允许自动提升CKAgentNXE.exe
. 这就是它点击的地方:这都是因为 Internet Explorer 沙箱。
因此,当 TouchEn Key 在 Internet Explorer 中作为 ActiveX 运行时,其完整性级别为低。以这种方式被沙盒有效地使其无法使用SendInput()
。通过允许CKAgentNXE.exe
从 Internet Explorer 沙箱运行并自动提升来规避此限制。一旦助手应用程序运行,沙盒中的 ActiveX 控件就可以连接到它并要求它做一些事情。喜欢打电话SendInput()
。
在 Internet Explorer 之外,这种方法毫无意义,但 TouchEn nxKey 也将工作委托给CKAgentNXE.exe
. 这对安全有影响。
假设我们有一个以低完整性级别运行的恶意软件。它可能是通过利用浏览器漏洞到达那里的,但现在它被困在那个沙箱中。它现在能做什么?为什么,就等着CKAgentNXE.exe
启动(迟早会发生),用它来突围!
我的概念验证应用程序要求CKAgentNXE.exe
为其生成假键盘输入:Win 键,然后是 C、M、D 和 Enter 键。这导致命令行提示符被打开,这个以中等完整性级别(默认级别)运行。然后,真正的恶意应用程序可以键入任意命令以在沙箱外运行代码。
并不是说真正的恶意应用程序会以这种可见的方式做事。CKAgentNXE.exe
还接受命令代码 5,例如它将任意 DLL 加载到任何进程中。这是一种更好的感染系统的方法,你不觉得吗?
至少这次强制性安全应用程序之一决定让自己有用并标记威胁:
关于 C:\Temp\test.exe 被 Malware/Win.RealProtect-LS.C5210489 感染的 AhnLab Safe Transaction 应用程序警告
恶意软件作者可能会找出触发此警告的原因并绕过它。或者他们可以启动网络套接字连接,以确保CKAgentNXE.exe
启动时无需像真正的银行网站那样激活 AhnLab 应用程序。但是为什么要打扰呢?这只是一个提示,并没有主动停止攻击。当用户点击删除恶意应用程序时,为时已晚——攻击已经成功。
如上所述,TouchEn nxKey 应用程序(它从驱动程序接收的加密键盘输入)以用户权限运行。它不是提升的应用程序,它没有特殊权限。那么如何限制对驱动程序功能的访问呢?
正确答案当然是:不是。系统上的任何应用程序都可以访问此功能。它只需要知道 nxKey 如何与其驱动程序通信。如果您想知道:该通信协议并不是非常复杂。
我不确定这里的想法是什么。TKAppm.dll
,执行驱动程序通信的库,使用 Themida 进行了混淆。Themida 背后的供应商承诺:
Themida® 使用 SecureEngine® 保护技术,当以最高优先级运行时,该技术会实施前所未见的保护技术来保护应用程序免受高级软件破解。
也许 nxKey 开发人员认为这将提供足够的保护来防止逆向工程。然而,在运行时连接调试器允许保存已经解密TKAppm.dll
的内存并将结果加载到 Ghidra 中进行分析。
标题为 TouchEn nxKey 的消息框。 文字说:检测到调试程序。 请关闭调试程序并重试。 TouchEn nxKey 将无法与后续键一起使用。 (如果系统是虚拟PC,请尝试真实PC。)
对不起,太迟了。我已经得到了我需要的东西。在安全模式下启动时,您的应用程序拒绝工作是没有用的。
无论哪种方式,我都可以编写一个微型(70 行代码)应用程序来连接到驱动程序并使用它来拦截系统上的所有键盘输入。它不需要提升,以用户权限运行就足够了。与网页不同的是,此应用程序还可以确保将此键盘输入传送到其目的地,因此用户不会注意到任何事情。创建键盘记录器从未如此简单!
最好的部分:这个键盘记录器与 nxKey 应用程序很好地集成在一起。因此 nxKey 会接收键盘输入,对其进行加密并将加密数据发送到网站。我的小键盘记录器也会收到相同的键盘输入,作为明文。
在开发内核驱动程序时,您应该了解一些事情:使驱动程序崩溃将导致整个系统崩溃。这就是为什么您应该格外确定您的驱动程序代码永远不会失败。
nxKey使用的驱动会不会失效?虽然我没有仔细看,但我无意中发现它可以。你看,应用程序将使用DeviceIoControl()向驱动程序请求指向输入缓冲区的指针。驱动程序通过调用MmMapLockedPagesSpecifyCache()创建此指针。
是的,这意味着这个输入缓冲区对系统上的每个应用程序都是可见的。但这不是主要问题。而是:如果应用程序再次请求指针会发生什么?好吧,司机会再打一个MmMapLockedPagesSpecifyCache()
电话。
在一个循环中执行此操作约 20 秒后,整个虚拟地址空间将耗尽并MmMapLockedPagesSpecifyCache()
返回NULL
。驱动程序不检查返回值并崩溃。砰,操作系统自动重启。
据我所知,这个问题是不可利用的(注意:我不是二进制利用方面的专家),但它仍然相当令人讨厌。
通常,当我披露漏洞时,它们已经被修复了。不幸的是,这次情况并非如此。据我所知,到目前为止,所有问题都没有得到解决。我不知道供应商计划何时解决这些问题。我也不知道他们计划如何向用户推出更新,特别是考虑到银行已经在分发比当前版本至少落后三个版本的构建。您还记得:没有自动更新功能。
即使报告这些问题也很复杂。尽管专注于安全,但 RaonSecure 并未列出任何类型的安全联系人。事实上,RaonSecure 没有列出任何联系人,除了首尔的电话号码。不,我不会打电话到韩国询问那里是否有人会说英语。
幸运的是,KrCERT 提供了专门供外国公民使用的漏洞报告表。此表单会经常出错并要求您重新输入所有内容,并且一些报告无缘无故地被网络防火墙拦截,但至少找到安全联系人的负担由其他人承担。
我在 2022 年 10 月 4 日向 KrCERT 报告了所有漏洞。我仍然试图直接联系一些 RaonSecure 高管,但没有得到任何回应。至少 KrCERT 确认在大约两周后将我的报告转发给了 RaonSecure。他们还注意到 RaonSecure 要求我提供电子邮件地址并希望与我联系。他们从来没有。
就是这样。90 天的披露截止日期是一周前。TouchEn nxKey 1.0.0.78 显然是在 2022 年 10 月 4 日发布的,同一天我报告了这些漏洞。在撰写本文时,它仍然是最新版本,并且此处描述的所有漏洞仍然存在。2018 年 1 月发布的最新版 TouchEn 浏览器扩展已有五年历史。
我怎么知道他们正在修复?好吧,多亏了我以前从未发生过的事情:他们在截止日期之前泄露了我的概念证明(意思是:几乎完全利用漏洞)。
看,我过去常常将文件直接附加到我的报告中。然而,这些附件经常会被过分热心的安全软件删除或以其他方式破坏。因此,我现在将演示问题所需的任何文件上传到我的服务器。指向我的服务器的链接始终有效。额外的好处:即使是与不沟通的公司,我也可以在日志中看到供应商是否访问了概念验证,这意味着我的报告是否到达了任何人。
几天前,我检查了访问 TouchEn nxKey 文件的日志。并立即看到了 Googlebot。果然:这些文件最终被列入了谷歌索引。
现在我使用一个随机的文件夹名称,它无法被猜到。而且我只与供应商共享链接。所以供应商一定在某处发布了一个公开可见的漏洞链接。
事实上他们就是这么做的。我找到了一个开发服务器,公开可见并被谷歌索引。似乎该服务器最初链接到我的概念验证页面。当我找到它时,它已经托管了供应商修改后的副本。
Googlebot 的第一个请求是在 2022 年 10 月 17 日。所以我不得不假设这些漏洞可以在披露截止日期前两个多月通过谷歌搜索找到。它们已被多次访问,很难判断是否只是产品的开发人员。
报告此问题后,开发服务器立即从公共互联网上消失了。尽管如此,我从未见过如此草率地处理安全敏感信息。
我们在 TouchEn nxKey 应用程序中发现了许多漏洞。通过尝试与键盘记录器作斗争,nxKey 开发人员构建了一个完美的键盘记录工具集,但未能限制对其的访问。但这个想法很好,不是吗?如果构建得当,它可能实际上是一个有用的安全工具?
问题是:受到保护的键盘记录器在什么级别上运行?在我看来,有四种选择:
CrossEXService.exe
同样以用户权限运行的进程。这实现了与我的拒绝服务攻击相同的结果,保护被有效禁用。因此,无论 nxKey 可能提供什么保护,它都依赖于不知道 nxKey 及其功能的攻击者。一般攻击可能会被挫败,但它不太可能有效抵御任何专门针对韩国银行或政府组织的攻击。
在这四个级别中,第 2 个级别可能可以修复。可以使应用程序CrossEXService.exe
以管理员权限运行。这将防止恶意软件干扰这个过程。然而,这种保护的有效性仍然取决于恶意软件无法进入用户的浏览器。
我看不出如何使这个概念可靠地对抗在其他级别上运行的恶意软件。