TouchEn nxKey：鍵盤記錄反鍵盤記錄解決方案

本文譯自：TouchEn nxKey: The keylogging anti-keylogger solution

我一周前寫過關于韓國的強制性所謂安全應用程序。我的旅程始于 RaonSecure 的 TouchEn nxKey，它引起了我的注意，因為相應的瀏覽器擴展程序擁有超過 1000 萬用戶——Chrome 網上應用店將顯示的最高數量。實際用戶數量可能要高得多，韓國幾乎所有計算機上都安裝了該軟件。

這并不是因為人們非常喜歡它：他們完全討厭它，導致平均評分為 1.3 分（滿分 5 星），并且有很多人呼吁廢除它。但是，如果您想在韓國進行網上銀行之類的操作，則需要使用它。

推動安裝該軟件的銀行聲稱它提高了安全性。人們稱其為“惡意軟件”和“鍵盤記錄程序”。我花了一些時間分析產品的內部運作，并確定后者更接近事實。該應用程序確實在設計上包含了關鍵的日志記錄功能，但未能充分限制對其的訪問。此外，各種錯誤的范圍從簡單的拒絕服務到促進遠程代碼執行。我總共報告了產品中的七個安全漏洞。

內容

• 背景
• TouchEn nxKey 究竟有什么作用？
• 網站如何與 TouchEn nxKey 通信？
• 濫用 TouchEn 擴展攻擊銀行網站
  • 旁注：類似于 TouchEn 的瀏覽器擴展
• 使用網站的鍵盤記錄功能
• 攻擊應用程序本身
• 濫用助手應用程序
• 直接訪問驅動程序的鍵盤記錄功能
  • 旁注：驅動程序崩潰
• 它會被修復嗎？
  • 旁注：信息泄露
• nxKey 概念是否可行？

背景

在我大致介紹了韓國的情況后，人們開始在各種韓國網站上討論我的文章。一條評論特別提供了我所缺少的重要信息：2005 年關于韓國外匯銀行黑客事件的兩則新聞報道[1] [2]。這些只是技術細節，但讓我試著解釋一下我是如何理解這一點的。

這在 2005 年的韓國顯然是一件大事。一個網絡犯罪團伙通過遠程訪問木馬設法從人們的銀行賬戶中竊取了 5000 萬韓元（當時約合 50,000 美元） 。這樣，他們不僅獲得了用戶的登錄憑據，還獲得了安全卡中的信息。據我所知，這張安全卡類似于索引 TAN，后者是 2012 年在歐盟廢除的第二因素身份驗證方法，其確切原因是容易被銀行木馬破壞。

用戶的計算機是如何感染這個惡意應用程序的？從描述來看，這聽起來像是使用瀏覽器訪問惡意網站時的路過式下載，很可能是瀏覽器漏洞被利用了。但是，也有可能用戶被誘騙安裝了該應用程序。有問題的瀏覽器沒有命名，但肯定是 Internet Explorer，因為韓國此時沒有使用任何其他瀏覽器。

現在新聞強調用戶沒有丟失或放棄他們的網上銀行憑證，他們沒有做錯任何事。網上銀行的完整性普遍受到質疑，銀行因沒有實施足夠的安全預防措施而受到批評。

2005 年在其他國家也有很多這樣的故事。雖然我不能說這個問題已經完全消除，但今天它已經不那么普遍了。一方面，網絡瀏覽器變得更加安全。另一方面，銀行改善了第二個因素。至少在歐洲，您通常需要第二臺設備來確認交易。并且您在確認時會看到交易詳情，因此您不會不小心確認轉賬給惡意行為者。

韓國選擇了不同的路線，公憤要求速效。第二個新聞報道指出了罪魁禍首：安全應用程序本可以阻止攻擊，但它的使用不是強制性的。銀行遵守。它承諾提供“反黑客”應用程序，并強制所有用戶使用它。

所以我能在 2006/2007 年左右找到第一次提到 TouchEn Key 可能不是巧合。當您將數據輸入網頁時，該應用程序聲稱會保護您的敏感數據。最終，開發了 TouchEn nxKey 以支持非 Microsoft 瀏覽器，這就是我研究的那個。

TouchEn nxKey 究竟有什么作用？

TouchEn nxKey 上的所有公共資源都表明，它以某種方式旨在通過加密鍵盤輸入來對抗鍵盤記錄器。這是我能找到的所有技術信息。所以我不得不自己想辦法。

依賴 TouchEn nxKey 的網站運行 nxKey SDK，它由兩部分組成：一堆在網站上運行的 JavaScript 代碼和一些服務器端代碼。下面是它的工作原理：

您在使用 nxKey SDK 的網站上輸入密碼字段。

nxKey SDK 的 JavaScript 代碼檢測到它并通知您本地的 nxKey 應用程序。

nxKey 應用程序在 Windows 內核中激活其設備驅動程序。

設備驅動程序現在攔截所有鍵盤輸入。鍵盤輸入不是由系統處理，而是發送到 nxKey 應用程序。

nxKey 應用程序加密鍵盤輸入并將其發送到 nxKey SDK 的 JavaScript 代碼。

JavaScript 代碼將加密數據放入隱藏的表單字段中。實際密碼字段僅接收虛擬文本。

您完成輸入登錄憑據并單擊“登錄”。

加密的鍵盤輸入與其他數據一起發送到服務器。

nxKey SDK 的服務器端部分對其進行解密并從中檢索明文密碼。常規登錄程序接管。

所以理論是：試圖記錄輸入該網站的數據的鍵盤記錄器只會看到加密數據。它可以看到網站使用的公鑰，但不會有相應的私鑰。所以沒辦法解密，密碼是安全的。

是的，這是一個非常好的理論。

網站如何與 TouchEn nxKey 通信？

網站如何知道計算機上安裝了特定的應用程序？它如何與之通信？

似乎這里正在發生范式轉變。最初，TouchEn nxKey 需要安裝其瀏覽器擴展。該瀏覽器擴展使用本機消息將請求從網站轉發到應用程序。并將響應發送回網頁。

然而，使用瀏覽器擴展作為中介不再是最先進的技術。目前的做法是網站使用WebSockets API直接與應用程序通信。不再需要瀏覽器擴展。

顯示網站 busanbank.co.kr 通過 touchenex_nativecall() 與 TouchEn 瀏覽器擴展通信。 該擴展反過來通過本機消息與應用程序 CrossEXChrome 通信。 另一方面，網站 citibank.co.kr 通過 127.0.0.1:34581 上的 WebSocket 直接與應用程序 CrossEXService 通信。

我不確定這種范式轉變究竟是從什么時候開始的，但還遠未完成。雖然韓國花旗銀行等一些網站專門使用新的 WebSocket 方法，但釜山銀行等其他網站仍在運行完全依賴于瀏覽器擴展的舊代碼。

這不僅僅意味著用戶仍然需要安裝瀏覽器擴展。它還解釋了盡管安裝了軟件但仍未被識別的頻繁抱怨。這些用戶安裝了不支持 WebSocket 通信的舊版本軟件。沒有自動更新。由于一些銀行仍在提供這些舊版本的下載，這是我最初犯的一個錯誤。

濫用 TouchEn 擴展攻擊銀行網站

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"。

通過 TouchEn 擴展發送消息以設置對某些函數的回調，同時還使用和setcallback覆蓋 JSON 響應屬性。"tabid":""``"reply":"malicious payload"

對回調的第一次調用立即發生。因此，將在銀行網站中調用回調函數，并將reply屬性中的惡意負載作為參數。

我們就快到了。一個可能的回調函數可能是eval，但還有最后一個障礙：TouchEn 在將屬性提供給回調之前傳遞該reply屬性。JSON.stringify()所以我們實際上得到eval("\"malicious payload\"")了并且這沒有做任何事情。

另一方面，也許目標頁面有 jQuery？調用$('"<img src=x onerror=alert(\'Hi,_this_is_JavaScript_code_running_on_\'+document.domain)>"')將產生預期的結果：

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 擴展的網站。并且韓國銀行強制用戶安裝的“安全”應用程序中沒有任何一個可以檢測或阻止這種攻擊。

旁注：類似于 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 實際上相信這一點，而不是查看OriginHTTP 標頭。因此，從某些合法使用 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 objectsconnector.connect();if (!connector.connected){// Application isn’t running, start it nowRunApplication("CKAgentNXE.exe");while (!connector.connected){Sleep(10);connector.connect();}}// Some IPC dance involving a mutex, shared memory and eventsconnector.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 日。所以我不得不假設這些漏洞可以在披露截止日期前兩個多月通過谷歌搜索找到。它們已被多次訪問，很難判斷是否只是產品的開發人員。

報告此問題后，開發服務器立即從公共互聯網上消失了。盡管如此，我從未見過如此草率地處理安全敏感信息。

nxKey 概念是否可行？

我們在 TouchEn nxKey 應用程序中發現了許多漏洞。通過嘗試與鍵盤記錄器作斗爭，nxKey 開發人員構建了一個完美的鍵盤記錄工具集，但未能限制對其的訪問。但這個想法很好，不是嗎？如果構建得當，它可能實際上是一個有用的安全工具？

問題是：受到保護的鍵盤記錄器在什么級別上運行？在我看來，有四種選擇：

在瀏覽器中。因此，一些惡意 JavaScript 代碼正在網上銀行頁面中運行，試圖捕獲密碼。該代碼可以簡單地阻止頁面激活 nxKey。

在系統中，具有用戶的權限。這個權限級別足以殺死CrossEXService.exe同樣以用戶權限運行的進程。這實現了與我的拒絕服務攻擊相同的結果，保護被有效禁用。

在系統中，具有管理員權限。這實際上足以卸載 nxKey 驅動程序并將其替換為木馬化副本。

在硬件方面。游戲結束，祝你好運嘗試任何基于軟件的解決方案。

因此，無論 nxKey 可能提供什么保護，它都依賴于不知道 nxKey 及其功能的攻擊者。一般攻擊可能會被挫敗，但它不太可能有效抵御任何專門針對韓國銀行或政府組織的攻擊。

在這四個級別中，第 2 個級別可能可以修復。可以使應用程序CrossEXService.exe以管理員權限運行。這將防止惡意軟件干擾這個過程。然而，這種保護的有效性仍然取決于惡意軟件無法進入用戶的瀏覽器。

我看不出如何使這個概念可靠地對抗在其他級別上運行的惡意軟件。

總結

以上是生活随笔為你收集整理的TouchEn nxKey：键盘记录反键盘记录解决方案的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。