Analysis of password control security technology and attack examples

Analysis of password control security technology and attack examples

The password control is a common control. This article mainly introduces some implementation and attack ideas of the security password control.

1. Comparison of the physical password keyboard and password control

Let's talk about the comparison between the password control in the program and the real-world password keyboard. Almost everyone has entered a password on a bank or an ATM machine. The keyboard you access when entering the password is a financial password keyboard. Generally, the password and keyboard at the counter carry a data line like a mouse, which is connected to the password and the bank processing terminal. The structure is as follows:

Obviously, if a bad guy wants to steal password information, there are two methods:

A. record users' input buttons on the terminal

B. Intercept user password input from the data line

The first method relies on the user's self-protection when entering the password, and the second method is not easy to implement. Do not underestimate this password and keyboard. The manufacturing standards of this password and keyboard are stipulated by the national standard. The national standard stipulates that the data flowing from the keyboard must be encrypted by the user, therefore, if you want to crack the password even if you want to intercept the data from the keyboard, you must first obtain the key used by the password and keyboard during the encryption process (symmetric encryption algorithm is used here ).

In fact, the password control is the software implementation of the password keyboard. In a software system that uses the password control (mostly a network verification system ), the entire software implementation of the password control is equivalent to the entire physical password keyboard. For the role of physical data lines and banking terminals, there is no absolute correspondence in the password control system. Because the password control may simply encrypt the data entered by the user and send it to the network, the network is the physical data line; in another case, the data generated by the password control flows to another module of the entire local program. At this time, the computer memory becomes the role of the physical data line.

In any case, the above physical password and keyboard must be safer than various password controls, because they are used in a limited number of occasions, and few people can access the password and keyboard, therefore, malicious attacks cannot be performed within the password and keyboard. The software-implemented password control is now too limited, because the environment of the user terminal is very complex and the permissions are very loose to be deployed on the user terminal.

2. Principles and attack methods of the soft keyboard and password control

There is no special password control in the built-in controls of Windows system. Instead, you only need to set an attribute password for the Edit Control of a SingleLine, in this way, the input content of this Edit is only displayed as an unidentifiable character. However, this native password control has only one point in terms of security: the user's entered password is not visually visible, but the entire password control still follows the Win32 message dispatch process, that is, by writing a standard program, you can obtain user input prior to the password space to record the password.

Therefore, many software vendors have made a variety of "Secure Password Controls" for security considerations. common types of password controls are as follows:

1. Low-level keyboard hook, change message parameters and dispatch path

2. Soft Keyboard, completely bypassing keyboard input messages

3. I haven't thought of it yet ......

The following describes the principles of the above two controls.

2.1 soft-keyboard password control

Because not many of the 2nd solutions are used, one of the reasons for not using this method is that the user experience is inferior to that of keyboard input. The password control is used to convert the keyboard input to the mouse key input. The mouse key message does not carry the original Password character, but is the coordinates of the key, then, the program maps the coordinates to the corresponding characters, and the F (x, y) follows in the ing process is designed by the program developers themselves and can be dynamically updated (in ascending order) in real time ).

Do not consider other protection measures first. If you want to attack such a security control, consider from the programmer who designs the control. If you want to obtain the user's input password, at least two conditions are required.

A. Click the coordinates (x, y)

B. Memory ing algorithm F (x, y)

Attackers can intercept the mouse and click the coordinates (x, y) and then calculate the user input based on the cracked F (x, y, this method may be effective for a keyboard and password control that is not fully protected, but it is still too troublesome. In fact, there is a shortcut, as long as the attacker identifies the user's mouse click operation on the keyboard, then, each time a user clicks the mouse, a screen is displayed, which can be full screen or partial. Then, the captured image is sorted to obtain the password data entered by the user, it completely bypasses the program's ing algorithm.

Therefore, we can see from the above attack methods that if the software disk password control is to be more secure, we must process the two events,

A. The message clicked by the user is not intercepted by other programs.

B. Black screen processing is performed on all Windows DC of the program in case of screenshot taking

I have introduced so much about the soft keyboard and password controls, but I am only introducing the principles and no practical code, but the principles and attack methods are very clear, therefore, if you are interested, you can help some vendors that use the soft keyboard and password controls to perform security tests.

2.2 low-level keyboard hook-type password control

This is a popular and typical cryptographic control implementation method. In this mode, the keyboard is the keyboard, the input box is the input box, and the only difference is the message dispatch path of the input box, every vendor tries their best to find a way to solve security problems in the Windows message processing mechanism.

In the normal input box, when receiving the user's keyboard input, the corresponding WM_CHAR message is sent. How does this message come from? When you press the next key, the keyboard driver generates the hardware interrupt IRQ, and then the HAL ing interrupt request level (IRQL). If this level is higher than the allowed level of the CPU, it will be interrupted, the CPU extracts the keyboard interrupt number, uses the interrupt number as the index to retrieve the corresponding descriptor in the IDT, and then executes a keyboard handler pointed to by the descriptor, the function of the keyboard interrupt handler is to process the original Keyboard Scan code to generate a Data Structure and then cache the data.

Generated by a Raw input thread (RIT) in the worker. After this IRP is completed, RIT is responsible for generating a key message using the data generated by Keyboard Events and placing it in the input queue of the corresponding GUI thread.

Then, the corresponding GUI thread uses GetMessage to get the message in the message loop, and a WM_KEYDOWN message will be taken out. If the GUI thread uses TranslateMessage to process the WM_KEYDOWN message, A WM_CHAR message is generated and stored in its POST message queue. The WM_CHAR message is retrieved next time you go to GetMessage, And the char carried by the message is passed into the corresponding Window Procedure, if you do not use TranslateMessage to process this message, no WM_CHAR message is generated.

The complete flowchart is as follows:

From the above description and flowchart, if an attacker wants to obtain the password entered by the user, it is easy to intercept the WM_CHAR message, with Spy ++, you can easily obtain all WM_CHAR messages in a native password input box. Therefore, the goal of the secure password control is to prevent attackers from intercepting WM_CHAR messages, or when the message WM_CHAR is intercepted, the VirtualKeyCode is false, and the real VirtualKeyCode has been processed. This is because only WM_CHAR is a plaintext record of user-typed data when one character is displayed from the user's key to the password box.

To protect the WM_CHAR message, you must obtain the WM_KEYDOWN message, as long as the message WM_KEYDWON is available, the system can bypass subsequent processing and calculate the Virtual Key pressed by the user before the system, and then save the Char corresponding to the case, then, a modified WM_KEYDOWN message is returned. You do not need to worry about the subsequent data. WM_KEYDOWN is modified, and Virtual Key is modified, as a result, the WM_CHAR generated when the TranselateMessage message is subsequently called is incorrect. Therefore, it is futile for attackers to intercept WM_CHAR.

The methods used to generate false WM_CHAR vary from vendor to vendor, for example, QQ is (filter 5000 words here ). For example, if a user's password is mypasswordisaccess, the char sequence returned by the control will be 1234556789054qqw55, that is to say, after each initialization of the x-bao security control, when you enter a key, the control will set a char ing char for this key. If you enter this key again next time, you do not need to set to directly return the char set last time. The policy is that after the user inputs the key, the control is responsible for generating the ing relationship. The ing value is generated in a simple way:

For example, the four-row key positions are arranged from top to bottom from left to right.

The principle mentioned above, to be implemented, will inevitably use a Windows technology, that is, the message-based Hook mechanism (the Hook and inline, IAT, SSDT and other hooks are not the same thing), because to process WM_KEYDWON and modify WM_CHAR before the system generates WM_CHAR, you must use a low-level keyboard Hook, WH_KEYBOARD_LL.

Analysis and Practice of 2.3 x-bao Security Password Controls

Well, it's not going to be discussed on paper. Find a target for analysis. To avoid the lawyer's letter, choose zhix baoba, the password control of zhixbao is used in the login and payment password input processes. both use the same password control. Let's debug it first.

As mentioned above, the password control uses the windows hook mechanism. Start with the SetWindowsHookEx function.

Code:

Then, operate the webpage to get the focus of the control, trigger the breakpoint, and view the stack:

Code:

 

Then let's take a look at the dynamic setting of two breakpoints:

Code:

Then the following operations are performed to retrieve and lose the focus of the control:

Code:

Then, let's take a look at the module where the Hook processing function is located and the offset when SetWindowsHookExW is called.

Code:

I will not debug the following. I will analyze the processing function directly. Find the module npAliSecCtrl, shell it, and find the offset ca008.

Then, let's go against it ...... I didn't finish the code, but it was just a general framework.

In fact, you only need to know the HOOK implementation mechanism. The principle of this control is to set a low-level keyboard HOOK when the control gets the focus, the function of this keyboard hook is to intercept WM_KEYDOWN, process the message, and modify the message. During debugging, it was also found that after a low-level keyboard Hook was set, no debugging Hook was set, which easily broke through this protection mechanism, as long as you set a lower-level keyboard hook after setting the hook at the right time, you can get the keyboard input message before the hook of the control, I don't know whether this is a design that is lacking in consideration. However, even if a debugging hook is added, it is not without any flaws. There are still ways to attack it.

2.4 x-bao security password control attack instances

As mentioned above, even if debugging hooks are added, the attack cannot be blocked because the Windows message Hook has a high level and some protection measures are implemented at such a high level of system, there is basically no way to achieve absolute security. For the password control supporting xbao, only one Inline Hook can be completely cracked.

Principle: Enter the browser's process memory space. Inline hooks User32! SetWindowsHookExW/A function analyzes the parameters of the function and determines that if the input module belongs to the target module and the hook type is A low-level keyboard hook, the original function is called. After the original function returns successfully, call the original function to set a low-level keyboard hook and then return. This is equivalent to adding a hook to the hook of the Control. This hook is our hook. We can get the keyboard input before the hook of the control to calculate the characters entered by the user, achieve the key record goal.

For xxxx reasons, I cannot provide the source code here. Only one graph and one bin are provided for your research.

Original address: http://bbs.pediy.com/showthread.php? T = 175448