 John2gQui Tacet ConsentitPremium
join:2001-08-10
England | reply to TonyKlein
Re: HTA Download, a new type of danger! As an aside, I read a monthly newsletter "Crack Talk". Terry Blount recommended in September 1999 that you delete the MSTA entry associated with .hta files because " a new hole found in IE5 allows anyone with a web page to place a program on a victim's hard disk that will be executed at the next reboot." He further writes " This is one hell of an exploit. Not many people realize that html pages renamed to .hta are executable in Windows"
He really was ahead of the field.
--
Better to remain silent and be thought a fool, than to speak and remove all doubt. |
|
| said by John2g:
As an aside, I read a monthly newsletter "Crack Talk". Terry Blount recommended in September 1999 that you delete the MSTA entry associated with .hta files because " a new hole found in IE5 allows anyone with a web page to place a program on a victim's hard disk that will be executed at the next reboot." He further writes " This is one hell of an exploit. Not many people realize that html pages renamed to .hta are executable in Windows"
He really was ahead of the field.
As someone who has programmed legitimate HTA apps, let me just say that clicking on a link to a HTA application won't run that application on your local system. It will prompt you to download it. After that, you'd have to double-click it (and get past Script Sentry or any other protective software) to run the application. I really don't think HTA files pose any more of a risk than running some EXE file you've downloaded.
As an example, click here and see what happens:
»www.jasons-toolbox.com/OpenPorts···orts.hta
--
-Jason Levine
http://www.jasons-toolbox.com/
http://www.PCQandA.com/
http://www.urateit.com/ |
|
 R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
| To clarify... ...clicking on a link to a HTA application won't run that application on your local system. It will prompt you to download it. "...as long as your registry has not been tampered with."
---------
I can modify your registry in such a way as to remove the "Download Dialog box" when clicking an .hta link. You can generally verify things are OK by checking in the File Types box and finding the "Confirm open..." box is checked.
HOWEVER, I can STILL fake you out by modifying your registry so that that box is incorrect. WinXP might be able to protect you from registry modifications by scripts, but Win98 cannot.
I must recommend Jason's Script Sentry as the superior solution to the HTA risk. Also, make sure your Internet zone is secure in the first place! (Goes without saying, but I said it anyway...)
[text was edited by author 2003-07-30 09:43:57] |
|
| reply to Jason Levine
said by Jason Levine:
I really don't think HTA files pose any more of a risk than running some EXE file you've downloaded.
Aren't running *any* downloaded EXE files considered the most risky of file types a user can run, as they are by nature executables themselves?If so, then it makes perfect sense then that HTA files don't pose any more of a risk then running some EXE's which are high risk in their own right.
Somehow, I don't think the comparison is appropriate though, but correct me if I'm wrong here. I understand the part about the .hta file having to be both downloaded and executed, but is that all so hard to pull off, really?
As we're all aware I'm sure that users who don't have their browser security sufficiently configured in their IE specific "non-trusted" zones, where "Drive-by downloads" of pretty much any malware seems to be fairly common occurrences.
I'm making the assumption, while not knowing for sure that a malicious website operator could cause an .hta file to be downloaded much like other executables and scripts are.
Continuing with the same premise, if that can be done I also can't see any reason why a batch file to execute it couldn't also be part of the same payload.
I would doubt a user that was already lacking good browser security would have sufficient layers of other protection to block a possible batch file from running the instructions to execute the HTA application.
So, I guess what I am trying to get at here is at least in my mind anyway, it seems to be quite a reasonable configuration for those among us that want to be secure in all know threats to at least take the added step in securing their system environment by removing the .hta file association with MSHTA.exe that John2g  advised earlier, unless their is a specific need on ones system of course for the HTA application functionality.
Am I making sense?
--
Any connection between your reality and mine is purely coincidental. |
|
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
| Yes, but there may be legitimate uses for HTA files. Grant it, not a lot - but Jason is one who programs with them.
The same argument was made about disabling Windows Script Host after the Love Bug. I program with VBscripts, so I love WSH. Jason uses a lot of WSH-run files as well.
Simply using Script Sentry is a MUCH more elegant solution. You can have your cake and eat it too. Eh, as they say.  I'm making the assumption, while not knowing for sure that a malicious website operator could cause an .hta file to be downloaded much like other executables and scripts are. Not directly -- in a similar fashion to .exe files or true WSH script files. I suspect an ActiveX control could contain something inside it that could be converted into an HTA file -- or even an .exe -- don't know for sure. But unless your registry has been tampered with (something ActiveX can do), IE will not automatically download an HTA file without your knowledge or consent.
HTML-embedded script (JavaScript on Web pages) does not have the power to either modify your registry nor rename files -- eh, as long as you are fully patched and no new exploits are found. 
[text was edited by author 2003-07-30 10:00:06] |
|
 antiseriousThe Future ain't what it used to bePremium
join:2001-12-12
Scranton, PA | reply to Jason Levine
said by Jason Levine:
As an example, click here and see what happens:
»www.jasons-toolbox.com/OpenPorts···orts.hta
... here's what happened when I did ... first, ZA asked a permission (gif 1), then I got an 'open ports' box from Jason's site (gif 2) ... the next 2 gif's show my ScriptSentry settings, but I never got a warning from SS - should I have seen one ? ...
--
... "Sometimes you're the Bird ... sometimes you're the Windshield" ... |
|
John2gQui Tacet ConsentitPremium
join:2001-08-10
England | said by antiserious:
should I have seen one ? ...
All I get is the normal download window.
--
Better to remain silent and be thought a fool, than to speak and remove all doubt. |
|
 spy1Welcome to AmerikaPremium
join:2002-06-24
Charlotte, NC | Yeah - me too.
Not to mention the fact that I've had the OpenPorts thing sitting on my Desktop for awhile now and never got alerted to the fact that it had anything to do with HTA stuff by anything here (specifically, WormGuard).
Went ahead and installed it and still never got an alert of any kind.
What's up with this? Pete
--
Compaq Presario 7110US, 1.3GHz Athlon w/384KB On-Chip Cache Memory, 768MB PC2100 DDR RAM, 60GB MAXTOR UltraDMA HD, WinXP Pro w/SP1, IE6.0 w/SP1,TDS-3, WormGuard, NOD32, SpyBlocker 6.2, OutPost Pro, ALL javacool programs, SBS&D, SPYCOP . |
|
|
|
| reply to R2
said by R2:
I must recommend Jason's Script Sentry as the superior solution to the HTA risk. Also, make sure your Internet zone is secure in the first place! (Goes without saying, but I said it anyway...)
I'm a Script Sentry fan as well, but there's something we've been overlooking.
We were discussing this over at Spywareinfo.com, and Mosaic1 rightly remarked that it would be exceedingly easy to simply excecute Mshta.exe directly, thus bypassing the Registry (and hence Script Sentry) altogether.
You can simply run the following command:
Mshta.exe "c:\openports.hta" (incidentally, on my XP system I apparently don't even need to enter the path to Mshta.exe), and Mshta.exe will execute that htafile whether Script Sentry or HTA Stop are enabled or not!
You can rename Mshta.exe, but this will still work.
Frightening stuff!
[text was edited by author 2003-07-30 12:54:10] |
|
John2gQui Tacet ConsentitPremium
join:2001-08-10
England | OK Tony, what is the answer then? |
|
 MarillaI Am My Own ArbiterPremium
join:2002-12-06
Belpre, OH | The answer, as always, is to maintain all of your 'layers' of security, properly updated and configured. This 'vulnerability', just like all of the rest, is mitigated by excersizing good security practices; Updated and strong AV/Anti-Malware software, not downloading and executing anything when you are not 100% aware of what it already is.. patching OS and application software.. avoiding sites which frequently attempt 'drive-by' installations... etc. |
|
| said by Marilla:
The answer, as always, is to maintain all of your 'layers' of security, properly updated and configured. This 'vulnerability', just like all of the rest, is mitigated by excersizing good security practices; Updated and strong AV/Anti-Malware software, not downloading and executing anything when you are not 100% aware of what it already is.. patching OS and application software.. avoiding sites which frequently attempt 'drive-by' installations... etc.
Eggzactly!
If someone were to offer an elegant way of "killing" and "enabling" mshta.exe itself we would already be a little safer.
And even then (quoting Mo again) it would conceivably be possible for an attacker to incorporate a (possibly renamed) mshta.exe into malware so that it would be completely self contained.
Admittedly, this is as yet in the realm of the theoretical, but nevertheless...  |
|
John2gQui Tacet ConsentitPremium
join:2001-08-10
England | said by TonyKlein:
Eggzactly!
If someone were to offer an elegant way of "killing" and "enabling" mshta.exe itself we would already be a little safer.
And even then (quoting Mo again) it would conceivably be possible for an attacker to incorporate a (possibly renamed) mshta.exe into malware so that it would be completely self contained.
Admittedly, this is as yet in the realm of the theoretical, but nevertheless...
What a little ray of sunshine you are today
--
Better to remain silent and be thought a fool, than to speak and remove all doubt. |
|
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1
| reply to TonyKlein
said by TonyKlein:
We were discussing this over at Spywareinfo.com, and Mosaic1 rightly remarked that it would be exceedingly easy to simply excecute Mshta.exe directly, thus bypassing the Registry (and hence Script Sentry) altogether.
You can simply run the following command:
Mshta.exe "c:\openports.hta" (incidentally, on my XP system I apparently don't even need to enter the path to Mshta.exe), and Mshta.exe will execute that htafile whether Script Sentry or HTA Stop are enabled or not!
You can rename Mshta.exe, but this will still work.
Frightening stuff!
I understand bypassing the registry -- YES, this will always be possible in the scenario where you can run command lines. The Command line itself performs the "association" so the registry is not queried. The same could be said of WSH and script files...
However, if a malware process of ANY type can run Commands similar to a Command line, you're screwed no matter what, aren't you? Forget about HTA. If it can run a Command line, it can run "format C:\"...
I don't understand how it can run an HTA file if you rename mshta.exe -- unless WinXP is causing mshta.exe to be re-created immediately via its System File Protection scheme (or whatever they call it). I would think renaming the executables -- eh, if the files aren't recreated -- should be effective.
You should not need to enter the entire path on the command line if mshta.exe exists in the "WinDir" or the "System" folders. The file will be found in there whether or not you specify the "fully qualified path".
_____________
Frankly, I don't understand what "running" mshta.exe in a process space has to do with any vulnerability. So what if mshta.exe is running or not? As long as it is called upon to run when needed, the fact that it is running at baseline or not should not matter, should it??
[text was edited by author 2003-07-30 20:10:58] |
|
| reply to TonyKlein
said by TonyKlein:
We were discussing this over at Spywareinfo.com, and Mosaic1 rightly remarked that it would be exceedingly easy to simply excecute Mshta.exe directly, thus bypassing the Registry (and hence Script Sentry) altogether.
You can simply run the following command:
Mshta.exe "c:\openports.hta" (incidentally, on my XP system I apparently don't even need to enter the path to Mshta.exe), and Mshta.exe will execute that htafile whether Script Sentry or HTA Stop are enabled or not!
You can rename Mshta.exe, but this will still work.
Frightening stuff!
I'm curious as to how you'd run that command from a web site. JavaScript in a web page can't run a local application. (I think there was a security hole a while back that let it do this, but I believe it's been patched.) You could use an ActiveX control, but once you have an ActiveX control running on someone's system, you pretty much have complete that control over the computer. (You can change the registry, manipulate files, even reboot the persons system using ActiveX.) I don't think a malicious web site operator could put up a link to "Mshta.exe c:\openports.hta" and have it work.
--
-Jason Levine
http://www.jasons-toolbox.com/
http://www.PCQandA.com/
http://www.urateit.com/ |
|
| reply to antiserious
said by antiserious:
... here's what happened when I did ... first, ZA asked a permission (gif 1), then I got an 'open ports' box from Jason's site (gif 2) ... the next 2 gif's show my ScriptSentry settings, but I never got a warning from SS - should I have seen one ? ...
Very interesting. Same thing actually happens here. I was able to track down the cause rather quickly though. If you go to HKEY_CLASSES_ROOT\CLSID\{3050f4d8-98B5-11CF-BB82-00AA00BDCE0B}\LocalServer32 and change the default value so that it's invalid (say to mshta1.exe), then SS comes up instead of mshta.exe. If, for some reason, you wanted to change this back, you could simply change the path to point back to mshta.exe.
--
-Jason Levine
http://www.jasons-toolbox.com/
http://www.PCQandA.com/
http://www.urateit.com/ |
|
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1 | reply to Jason Levine
said by Jason Levine:
You could use an ActiveX control, but once you have an ActiveX control running on someone's system, you pretty much have complete that control over the computer. (You can change the registry, manipulate files, even reboot the persons system using ActiveX.)
Exactly my point above. If something malicious can run a Command line of code like that, then HTA is the LEAST of your problems! quote:
If you go to HKEY_CLASSES_ROOT\CLSID\{3050f4d8-98B5-11CF-BB82-00AA00BDCE0B}\LocalServer32 and change the default value so that it's invalid (say to mshta1.exe), then SS comes up instead of mshta.exe.
That is because IE never uses the basic Windows Explorer associations of File extension to File Type to Open Command. Instead, it usually goes through the MIME Content type associations and gets the executable from the InprocessServer32 or (in this case) the LocalServer32 keys of the CLSID -- if specified.
Script Sentry could be modified to alter the LocalServer32 association of the ClassID to be "ScriptSentry.exe" as well -- and then protection would be automatic -- I suspect. |
|
| said by R2:
Script Sentry could be modified to alter the LocalServer32 association of the ClassID to be "ScriptSentry.exe" as well -- and then protection would be automatic -- I suspect.
It should be. And until I get around to doing this, here's a WSH script that will automatically do it for you. (I'll try to put this on my web site in the next few days, but things have been really hectic lately. Baby's due sometime in the next month or so! )
--
-Jason Levine
http://www.jasons-toolbox.com/
http://www.PCQandA.com/
http://www.urateit.com/ |
|
R2R NotPremium,MVM
join:2000-09-18
Long Beach, CA
kudos:1 | Here is a visual of how the "Internet Explorer" associations work:File extension (.hta) -> Content Type (applicaition\hta)
MIME Content Type -> MIME CLSID ({3050f4...})
MIME CLSID -> InprocServer32 or LocalServer32 (MSHTA.EXE) You can break the association anywhere along the chain and this should stop IE from automatically running .hta files with MSHTA.exe.
(I believe InprocServer32 takes precedence over LocalServer32 -- but I am not sure... yet. So, in theory, if you stick ScriptSentry.exe in the InprocServer32 value you might intercept .hta files before mshta.exe. Just a thought.):)
You should have ONE more option. Presently, the htafile File Type has NO EditFlag entry. See (no value) in the image. You could force IE to display the Download Dialog box whenever it encounters an .hta file by adding a Binary EditFlags value under htafile and setting it to 00 00 01 00. |
|
John2gQui Tacet ConsentitPremium
join:2001-08-10
England | reply to Jason Levine
said by Jason Levine:
It should be. And until I get around to doing this, here's a WSH script that will automatically do it for you.
Before I run this, what does it do? It is not that I don't trust you: I just like to know what is going on before I do.
--
Better to remain silent and be thought a fool, than to speak and remove all doubt. |
|
