密码控件安全技术浅析及攻击实例
https://bbs.pediy.com/thread-175448.htm
密碼控件是一個很常見的控件，這篇文章主要介紹一下安全密碼控件的一些實現思路和攻擊思路。
1 物理密碼鍵盤和密碼控件的對比
先說一下程序中的密碼控件和現實中的密碼鍵盤的對比。幾乎每個人都在銀行或者ATM機器上輸入過密碼，那在輸入密碼的過程中你接觸到的那個鍵盤就是一個金融密碼鍵盤。一般柜臺的密碼鍵盤都像鼠標一樣帶一個數據線，這個數據線就是連接密碼鍵盤和銀行處處理終端的。結構圖如下：
上圖顯而易見，如果一個壞人想要去竊取密碼信息，由兩個方式：
A． 在終端記錄用戶的輸入按鍵
B． 從數據線中截獲用戶密碼輸入
對于第一種方法，就靠用戶在輸入密碼時候的自我保護了，而第二種方法也不是輕易能實現的。不要小瞧了這個密碼鍵盤，這個密碼鍵盤的制造標準都是有國標規定的，國標規定的一點是：從鍵盤流出的數據一定要是用戶輸入加密后的數據，所以即使截獲到鍵盤流出的數據想要破解出密碼也需要先得到該密碼鍵盤在加密過程中使用的密鑰(這里使用的是對稱加密算法)。
其實密碼控件就是密碼鍵盤的軟件實現，在一個使用密碼控件的軟件系統中(多是網絡校驗系統)，密碼控件的整個軟件實現就相當于整個物理的密碼鍵盤，對于物理的數據線路和銀行終端這樣的角色，在密碼控件系統中沒有絕對的對應。因為密碼控件可能只是簡單的把用戶輸入的數據加密后發送到網絡上，這時候網絡就是物理的數據線路；而另一種情況是用密碼控件產生的數據流向整個本地程序的另一個模塊，這時候計算機內存就成為了物理的數據線路的角色。
無論如何，上述的物理密碼鍵盤肯定要比各種密碼控件安全，因為他們使用的場合有限，能夠接觸到密碼鍵盤內部的人很少，所以就無法從密碼鍵盤的內部來做一些惡意攻擊行為。而軟件實現的密碼控件就現對顯得捉襟見肘了，因為要部署到用戶終端，而用戶終端的環境十分的復雜，并且權限十分的寬松。
2 軟鍵盤密碼控件原理和攻擊方法
Windows系統的內置的控件中沒有專門的密碼控件這一說，而只是對一個SingleLine的Edit控件設置一個屬性password，這樣就實現了這個Edit的輸入內容只會顯示成一種不可識別的字符。但是這種原生的密碼控件從安全的角度來說就只有一點：從視覺上看不到用戶輸入的密碼，但是整個密碼控件仍然遵循Win32 消息派遣處理流程，也就是說，寫一個標準的程序就可以達到先于密碼空間獲得用戶輸入從而記錄密碼的效果。
因此很多軟件廠商出于安全的考慮就做出了各式各樣的“安全密碼控件”，常見的密碼控件類型：
1. 低級鍵盤鉤子，改變消息參數以及派遣路徑
2. 軟鍵盤，完全繞過鍵盤輸入消息
3. 暫時還沒想到……
下面簡單介紹一下以上兩種控件的原理
2.1 軟鍵盤式密碼控件
由于第2種方案使用的不是很多，所以簡單介紹，這種方法使用不多的原因之一就是用戶體驗不如鍵盤輸入。這種密碼控件的方法就是把鍵盤輸入轉為鼠標按鍵輸入，而鼠標按鍵消息中并沒有攜帶原始的密碼字符，而是按鍵的坐標，然后程序把坐標映射到相應的字符，而映射過程中遵循的F(x,y)是程序開發者自行設計并且可以實時動態更新(變序)。
先不考慮其他的保護措施，如果要攻擊這種安全控件，從設計這種控件的程序員的角度來考慮，如果要獲取用戶輸入密碼，至少需要兩個條件
A． 鼠標點擊坐標(x,y)
B． 內存中映射算法F(x,y)
攻擊者可以截獲鼠標點擊坐標(x,y)然后根據破解出來的F(x,y)來計算出用戶輸入，這種方法對于一個沒有做到全方位保護的軟鍵盤密碼控件可能有效，但是還是太麻煩了，其實有個捷徑，攻擊者只要識別出用戶的鼠標點擊操作發生在軟鍵盤上，然后在每次用戶點擊鼠標時就來一個屏幕截圖，全屏or局部都可以，然后把截取的圖片排序，就可以得到用戶輸入的密碼數據了，完全繞過程序的映射算法。
所以從以上攻擊方法可以看出，軟件盤密碼控件如果要做到更安全那就必須對兩個事件進行處理，
A． 用戶點擊鼠標的消息不被其他程序截獲
B． 發生截屏操作時對本程序的所有窗口DC做黑屏處理
關于軟鍵盤密碼控件就介紹這么多，只是原理性的介紹，并沒有實踐代碼，但是原理和攻擊方法已經十分清晰了，所以有興趣的同學可以幫助一些采用軟鍵盤密碼控件的廠商做下安全測試。
2.2 低級鍵盤鉤子式密碼控件
這個就是現如今流行并且典型的密碼控件實現方式了，這種方式下鍵盤還是那個鍵盤，輸入框還是那個輸入框，唯一的不同是這個輸入框的消息派遣路徑，賤了不少，各個廠商都想方設法的在Windows消息處理機制中尋找解決安全問題的途徑。
正常的輸入框，在接收用戶的鍵盤輸入時會相應WM_CHAR消息，這個消息是如何來的呢？當按下一個鍵，鍵盤驅動產生硬件中斷IRQ，然后經過HAL映射中斷請求級別(IRQL)如果這個級別比CPU的允許的級別高，那就發生中斷，CPU取出鍵盤中斷號，然后用該中斷號作為索引取出IDT中的對應的描述符，然后執行該描述符所指向的一個鍵盤處理程序，鍵盤中斷處理程序的作用就是處理原始的鍵盤掃描碼生成數據結構，然后緩存數據。
然后就是鍵盤驅動的工作，鍵盤驅動的工作就是為了完成設備棧頂部的一個功能號為IRP_MJ_READ的IRP，這個IRP是win32子系統進程csrss.exe中的一個線程RIT(Raw input thread)產生的，當這個IRP被完成后，RIT負責用鍵盤事件產生的數據生成一個按鍵消息并且放入對應的GUI線程的輸入隊列中。
而后對應的GUI線程在消息循環中使用GetMessage獲取消息，就會取出一個WM_KEYDOWN消息，然后如果該GUI線程中使用了TranslateMessage處理這個WM_KEYDOWN消息，則會生成一個WM_CHAR消息存入自身的POST消息隊列，然后下次再去GetMessage的時候就會取出WM_CHAR消息，并且把該消息攜帶的char傳入相應的Window Procedure，如果沒有使用TranslateMessage處理這個消息就不會產生WM_CHAR消息。
完整的流程圖如下：
從上面的描述以及流程圖來看，如果作為一個攻擊者想要獲取用戶輸入的密碼，很簡單的做法就是截獲WM_CHAR消息，的確是這樣的，用Spy++就可以輕而易于的獲得一個原生密碼輸入框的所有WM_CHAR消息，所以安全密碼控件的目標就是讓攻擊者無法截獲WM_CHAR消息，或者截獲到WM_CHAR消息的時候這個VirtualKeyCode是假的，而真正的VirtualKeyCode已經被處理。因為在從用戶按鍵到密碼框多出一個顯示字符的過程中只有WM_CHAR這個消息是明文記錄了用戶鍵入的數據。
對于保護WM_CHAR消息的做法，必然是要在得到WM_KEYDOWN這個消息的時候就進行，因為只要有了WM_KEYDWON這個消息就可以繞過系統后續的處理先于系統計算出用戶按下的Virtual Key，然后保存這個案件對應的Char，然后再返回一個修改過的WM_KEYDOWN消息，后面的數據都不用再管了，WM_KEYDOWN被修改，Virtual Key被修改，導致后續調用TranselateMessage消息時產生的WM_CHAR也不正確，所以攻擊者就算截獲到WM_CHAR也是徒勞的。
產生假WM_CHAR的的方法各個廠商迥異，比如QQ的就是(此處過濾5000字)。再比如支x寶，如果一個用戶的密碼是mypasswordisaccess，那么按照這個鍵序列輸入后，控件返回的char序列會是1234556789054qqw55，也就是說在支x寶安全控件每次初始化之后，當用戶輸入一個鍵，控件就會為這個鍵設置一個映射char，如果下次用戶再輸入這個鍵，那就不用設置直接返回上次設置的char，策略就是用戶輸入鍵之后控件負責生成映射關系，這個映射的值的產生方式很簡單：
如上圖的四行鍵位，從上到下從左到右排列。
上面說了原理，要實現的話，必然用到Windows的一種技術，那就是基于消息的Hook機制了（此Hook跟inline，IAT，SSDT等Hook完全不是一回事），因為要處理在系統生成WM_CHAR之前就處理WM_KEYDWON并且修改，就必須要使用低級鍵盤鉤子，WH_KEYBOARD_LL。
2.3 支x寶安全密碼控件原理分析實踐
好了，不紙上談兵了，找個靶子分析分析吧，為了避免律師函，還是選擇支x寶吧寶，支x寶的密碼控件用在了登陸和支付密碼的輸入過程中，兩處使用的都是同一個密碼控件，先來調試下吧。
按照前面的講到的，該密碼控件使用了windows hook機制，那就先從SetWindowsHookEx這個函數入手吧。
| 1 2 3 4 | ntdll!DbgBreakPoint: 00000000`77410530 cc int 3 0:209> bp USER32!SetWindowsHookExW 0:209> g |
然后操作網頁，讓控件獲取焦點，觸發斷點，看下堆棧：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 | (271c.4d7c): Break instruction exception - code 80000003 (first chance) Breakpoint 0 hit USER32!SetWindowsHookExW: 76d77603 8bff mov edi,edi 0:173:x86> kvn L10 # ChildEBP RetAddr Args to Child 00 4000ba84 73e94267 0000000d [COLOR=red]5c1cca08 5c1c0000[/COLOR] USER32!SetWindowsHookExW (FPO: [Non-Fpo]) *** WARNING: Unable to verify checksum?for?npAliSecCtrl.DLL *** ERROR: Symbol?file?could not be found. Defaulted to?export?symbols?for?npAliSecCtrl.DLL - 01 4000bab4 5c1ccaf5 0000000d 5c1cca08 5c1c0000 IEShims!NS_SetWindowsHookEx::APIHook_SetWindowsHookExW+0x6b (FPO: [Non-Fpo]) WARNING: Stack unwind information not available. Following frames may be wrong. 02 4000bb04 5c1c62d2 00140154 [COLOR=red]00000007[/COLOR] 0014050a npAliSecCtrl!NP_Initialize+0x21c7 03 4000bb50 76d662fa 4e1c3070 00000007 0014050a npAliSecCtrl!NP_Shutdown+0x269a 04 4000bb7c 76d66d3a 05940920 00140154 [COLOR=red]00000007[/COLOR] USER32!InternalCallWinProc+0x23 05 4000bbf4 76d66de8 00000000 05940920 00140154 USER32!UserCallWinProcCheckWow+0x109 (FPO: [Non-Fpo]) 06 4000bc50 76d66e44 010e22c0 00000000 00000007 USER32!DispatchClientMessage+0xe0 (FPO: [Non-Fpo]) 07 4000bc8c 775b010a 4000bca4 00000000 4000bde0 USER32!__fnDWORD+0x2b (FPO: [Non-Fpo]) 08 4000bcc4 5c1c9054 00140154 4e1c2f1c 00000001 ntdll_775a0000!KiUserCallbackDispatcher+0x2e (FPO: [0,0,0]) 09 4000bcfc 5c1c5d79 0014050a 00000007 000c0822 npAliSecCtrl!NP_Shutdown+0x541c 0a 4000bd4c 76d662fa 4e1c2f1c 4000c01c 000c0822 npAliSecCtrl!NP_Shutdown+0x2141 0b 4000bd78 76d66d3a 05940d80 0014050a 00000007 USER32!InternalCallWinProc+0x23 0c 4000bdf0 76d66de8 00000000 05940d80 0014050a USER32!UserCallWinProcCheckWow+0x109 (FPO: [Non-Fpo]) 0d 4000be4c 76d66e44 00e9fdf0 00000000 00000007 USER32!DispatchClientMessage+0xe0 (FPO: [Non-Fpo]) 0e 4000be88 775b010a 4000bea0 00000000 4000bf38 USER32!__fnDWORD+0x2b (FPO: [Non-Fpo]) 0f 4000bec0 5c1c6df4 0014050a 00000000 4e1c2ed4 ntdll_775a0000!KiUserCallbackDispatcher+0x2e (FPO: [0,0,0]) |
然后看一下動態的設置兩個斷點：
| 1 2 3 4 5 6 | 0:170:x86> bp USER32!SetWindowsHookExW?".printf \"Hit USER32!SetWindowsHookExW\\r\\n\"; g" 0:170:x86> bp USER32!NtUserUnhookWindowsHookEx?".printf \"Hit USER32!UnhookWindowsHookEx\\r\\n\"; g" 0:170:x86> bl 0 e x86 76d8f52b 0001 (0001) 0:**** USER32!NtUserUnhookWindowsHookEx?".printf \"Hit USER32!UnhookWindowsHookEx\\r\\n\"; g" 1 e x86 76d77603 0001 (0001) 0:**** USER32!SetWindowsHookExW?".printf \"Hit USER32!SetWindowsHookExW\\r\\n\"; g" 0:170:x86> g |
然后就來來回回操作讓控件獲取和失去焦點：
| 1 2 3 4 5 6 7 8 9 10 11 12 13 | (271c.1618): Unknown exception - code 800706ba (first chance) Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx Hit USER32!SetWindowsHookExW Hit USER32!UnhookWindowsHookEx |
然后看一下調用SetWindowsHookExW的時候，設置的Hook處理函數所在模塊以及偏移
| 1 2 3 | 0:173:x86> lm a 5c1c0000 start end module name 5c1c0000 5c27d000 npAliSecCtrl C (export?symbols) npAliSecCtrl.DLL |
下面就不調試了，直接去分析這個處理函數了，找到模塊npAliSecCtrl，先脫殼，然后找到偏移ca008
然后就逆吧……我沒有把這些代碼逆完，只是一個大致框架出來了。
其實只要知道他的HOOK實現機制就Ok了，這個控件的原理就是當控件獲取焦點的時候就設置一個低級鍵盤鉤子，這個鍵盤鉤子的作用就是截獲WM_KEYDOWN然后處理消息，修改消息。在調試中還發現，在其設置了一個低級鍵盤鉤子之后并沒有再設置一個調試鉤子，這樣就很容易突破這種保護機制了，只要照準時機在他的低級鍵盤鉤子設置后再設置一個低級鍵盤鉤子，那么就可以先于控件自身的鉤子獲取到鍵盤輸入消息了，不知道這個是否屬于考慮欠缺的一個設計，不過即使加一個調試鉤子，也并不是毫無破綻的，仍讓有方法可以攻擊。
2.4 支x寶安全密碼控件攻擊實例
上面說了即使加了調試鉤子，也還是不能阻止攻擊的，原因是Windows 消息鉤子的層次太高了，在如此高的系統層次上面去做一些防護，基本沒有辦法做到絕對安全。對于支x寶的密碼控件，只要一個Inline Hook就可以完全破除了。
原理：進入到瀏覽器的進程內存空間，Inline Hook住User32!SetWindowsHookExW/A函數，分析該函數的參數，判斷如果傳入的模塊是屬于目標模塊并且鉤子類型是低級鍵盤鉤子，則調用原函數，等待原函數返回成功之后，再調用原函數設置一個低級鍵盤鉤子，然后返回。這樣就相當于在控件本身的鉤子之上加了一個鉤子，而這個鉤子是我們的鉤子，我們可以先于控件鉤子得到鍵盤輸入，從而計算出用戶輸入的字符，達到鍵盤記錄的目的。
xxxx種原因，我不能在這里提供源碼，只有一圖和一個bin供各位研究了。
轉載于:https://www.cnblogs.com/davidwang456/articles/8944441.html
總結
以上是生活随笔為你收集整理的密码控件安全技术浅析及攻击实例的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 登录抓包逆向分析学习笔记
- 下一篇： 爬虫提取非结构化数据