Internet Explorer HexEdit Hack

684867

-------------------------------
Recently I set out to develop a new hijacker which would allow me to find means to discover and disable the threat. The following loosely describes what was finished at 0630 CST this morning, tested and finally destroyed (since I have no intent on its release).
-------------------------------
Objective:

Hexedit Internet Explorer (iexplore.exe) in such a way as to "hijack" the end-user's homepage and prevent changes thereto, while eliminating any traces that would cause its discovery by traditional means.

-------------------------------
Methodology:

[Note: no code examples are here, as I do not want to help anyone perform this hack. My time doing this is valuable and not subject to free exchange.]

Problem 1: Identify places in the executable where hijacker code can be inserted.

Solution 1: Use recursion to search file for repeating sequences of code. Create "spaghetti code" loops to reuse these repeating sequences (effectively compressing the executable). This allows space for the hijacker.

Problem 2: Identify "hook" location(s).

Solution 2: Identify code which loads webpages from given input. This is the hook point. It does not disturb the target computer's registry, address bar or other locations. The hook is on the back side of all operations and thus more difficult to detect.

Problem 3: Exploiting the vulnerability.

Solution 3: Insert jump code before web-page loading function is called. Jump code references the malicious hijacker routine and recieves all parameter information. The hijacker routine is composed of two parts: (a) Decoder and (b) Caller. Decoder reads an encrypted hijack URL hardcoded into the routine's lower space, then decodes the routine before passing the raw data to the caller. Caller then calls the native web-page loading routine with hijacked parameter information.

Problem 4: Avoiding discovery

Solution 4: This exploit will only be discovered by checksum analysis. If using Assembly language, it is possible to modify the executable without altering the file size. Timestamps can then be changed by hand to prevent detection through this means. [Caveat: a compiler is never a good substitute for a good assembly programmer, of which I am only moderate. You cannot keep the file size unless and until you identify certain areas of iexplore.exe that can be optimized to create a few bytes of extra space. Compression is not enough.]

Problem 5: Spread/Distribution [theoretical]

Solution 5: The spread of this hijacker can occur through uploading of the executable to the drive and alteration of the registry, using the PendingFileRenameOperations key in HKLM/SYSTEM/CURRENT CONTROL SET/CONTROL/SESSION MANAGER to rename the trojanized iexplore.exe as the original during the target-machine's next boot cycle.

Problem 6: Legality

Solution 6: A long legalese EULA which convinces the user to agree to alter the iexplore.exe and its functionality should protect the hacker from the law.

--------------------------------------
Analysis:

To prevent this sort of hijack requires component-component/executable- executable authentication mechanism. There should be some means in the op/sys to check MD5 checksums of any object in the machine prior to execution.

Ultimately, however, because of problem/solution 6, education of the user is more important.


****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

Recently, being now unemployed and with copious amounts of time on my hands while pursuing interviews I decided to continue my foray into the world of browser hijacking. I brought my trojanized version of iexplore.exe from the recycle bin (which thankfully I forgot to empty) and I decided to see if I could identify the malware using conventional tactics.

In the course of the experiment I infected a known good machine using a simple batch file from a floppy disk. (Not exactly an elegant method but it is still very effective). I rebooted the machine for good measure and launched Internet Explorer(IE). Surely enough, the machine was hijacked (to mozilla.org no doubt).

Typical tactics required that I first use tools|internet options to check the homepage, which read the former default--a webpage which would identify the target computer's owner, who would not want to be known in this project. I clicked "use defaults" to reset the homepage (more just to see what would happen). Nothing happened. The homepage remained as it should have been.

From this perspective as the hypothetical technician faced with a hijacker, I entered the system registry. I found some malware on the computer I had not intended to find, but this would be expected in a "real world" case. Once this was eliminated, I rebooted the computer and found that the machine (much to my "surprise") was still hijacked. All told this took 25 minutes, thus far.

My next step was to look to diagnostic tools. I ran regmon (downloaded from www.sysinternals.com ). Regmon detected, as I had intended, all of the typical registry acceses. Nothing stood out at that time. The same was found of filemon (also downloaded from sysinternals) and process explorer.

Later I duplicated my filemon/regmon experiments with a known good copy of IE on the same machine. I compared the two files with highlighter and paper to discover a minute difference in timing. Registry accesses with the legitimate IE were different from the trojanized IE. This is due to my reordering of code in the executable file while hexediting the IE file.

At the point were I began comparing to known good log files and looking at timing I exceeded the typical operating procedures of technical support agents who face this issue daily. This attack, therefore, represents a high severity in terms of difficulty to remove/identify. It reveals the major security flaw in existing program/system design and the need for a new way of thinking.

****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

Objective:

To explore the scope of the hexedit vulnerability as a means for browser
hijacking.

Analysis:

The hijacking of Internet Explorer (IE) by itself is not a difficult task. In two hours this morning (0245-0500) I wrote and tested a simple registry-based hijacker that touched on all of the usual places needed to (1) alter the registry and hijack IE browser settings, (2) alter the run keys to execute the trojan itself each time the machine boots, (3) alter APPINIT_DLLs to again reinfect the machine regularly and (4) corrupt the HOSTS file to block anti-virus sites.

This is simple and profitable for spyware companies in the short term. Since the industry now knows how simple the problem is in reality, the solution is emerging (e.g. Trendmicro now refers to the about:blank hijacker using se.dll as trojan_startpage.jz). Something must escalate or the hijacking will end...as will the profits.

The possibility of an escalated threat lead me to an experimental attack using a hex editor to alter the IE executable so as to conceal the hijacker in a trojanized browser. The only recourse in the event of such an attack is the manual replacement of the executable. Should more effort be made, allowing for the mutual support of the trojanized executable by one or more other executables, then it is feasible that the elusive beast will replace itself after identification. (This would require a considerable effort beyond my skills with assembly and the available space in the executable for such operations.)

My next thought on completion of this hijacker was the scope and nature of the vulnerability. Therefore, I have expanded the attack to include Netscape Navigator and Mozilla FireFox. Open-source browsers should be easier to hack since this can be done in the higher-level language used to develop the original browser. However, there is a significant possibility that rewriting the code in C++ will result in an unconcealable trojan. REMEMBER: the executable must have the same size, version and timestamp.

Hexediting an existing trojan seems to be the best option. Hexediting the executables allows the attacker to create a trojan package which will be downloaded to the target machine by the user. This package will then be launched, at which time it may copy the browser executable and alter the file's code and structure. The file can then be set for renaming as the original file.

The expanded attack will require the same process as in the case of IE. However, one must remember that, for instance, Mozilla does not make use of the Windows registry (hence the difficulty hijacking this browser). Secondly, open-source projects mean they can be altered. The installation/distribution package must include signature patterns for certain areas of the executable so as to allow the package to identify the locations whereat trojan code can be inserted.

Some installations of open-source browsers are compiled when installed on a target system, rather than having been downloaded as a binary. In these cases, the browser may be altered to suit the particular environment. The author is at present uncertain as to whether this is the case.

At this time the vulnerability is serious. The vulnerability is defined as the Operator, who must allow the delivery mechanism to be downloaded or executed on the target machine. There is no mechanism in place in Windows to counter this sort of vulnerability. Possible solutions have been proposed by the author, to include checksum testing by the component loader of the operating system and component authentication during run-time.


****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.

684867

I have searched for a means to repeat the hexedit attack I performed on IE against Mozilla. I have been unable to succeed at this attack for a month now.

In conclusion I have determined that Mozilla is more secure from this attack and thus a better browser.




****************************************
Excellence Breeds! Go Hard or Go Home.

Let Penguins rule the earth.
Break some windows today.