Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Computing > Computer Support > Re: Trojan got through to JUST IE and not FireFox

Reply
Thread Tools

Re: Trojan got through to JUST IE and not FireFox

 
 
VanguardLH
Guest
Posts: n/a
 
      01-04-2011
Lookout wrote:

> Windows XP Pro
> All Svc packs
>
> While using Firefox AND Yahoo chat a virus program popped up saying
> I'm infected and it's scanning for problems. Seen this before. Shut
> things down, tried do get updates for SuperAntiSpyware and that was
> blocked. Scanned with MalwareBytes and SuperAntiSpyware and found
> nothing. HOWEVER when I got back on I found I still couldn't update
> SuperAntiSpyware AND Yahoo chat was still down BUT FireFox was fine.
> Checked and the Proxy Server settings on IE had been changed.
>
> So..how do I find out which port this got through that both IE and
> SuperAntiSpyware use and how do I stop it from happening? My Windows
> Firewall IS ON.
>
> Thanks


Never click on anything presented in the rogueware web page. Don't even
click on the Yes/Cancel links presented in a fake dialog. The clicking
action, even when you are trying to exit, can result in a download (but
then IE should be configured to alert you about the download AND trying
to run it after downloaded - but then users do clicking they shouldn't).

Just kill the iexplore.exe process using Task Manager. To make it
convenient, I defined a shortcut in a handy toolbar in the Windows
taskbar that runs "%windir%\system32\taskkill.exe /im iexplore.exe /f".
That kills off ALL instances of IE.

It is possible for script within a web page to load another instance of
the web browser but which has no window; i.e., it is a hidden instance.
You'll see it using Task Manager's Processes tab - if you could ever
figure out which instance of iexplore.exe is for the hidden instance and
which ones are for the okay and visible instances. While the hidden
instance is running, it can affect the visible instances. That's why
you need to kill off ALL instances of the web browser.

When landing on a malicious, phishing, rogue, or malware site, don't
assume any clicking they make you do is on the up and up.
 
Reply With Quote
 
 
 
 
VanguardLH
Guest
Posts: n/a
 
      01-04-2011
Also, you might consider limiting what actions you allow the web browser
or any other Internet-facing application to commit on your host. Even
if you refuse to login under a limited account, you can still run a
program under a LUA (limited user account) token while logged in under
an admin-level account. See the following for a long explanation.

Security experts usually recommend that users log into a limited user
account (LUA) to more securely surf the web. When logged under a LUA,
privileges are reduced on the web browser will severely curtails the
damage that malware can perform when the web browser is the infection
vector into your computer. Under a limited account, the user cannot
install software. This all sounds nice except that users often need the
privileges of an admin-level account to run their applications, plus
they cannot install updates to Windows when using the web browser to
visit the Windows Update site (after all, the web browser has limited
privileges so it can't install anything). So how does the user that
wants to log under an admin-level account make sure their web browser is
running under limited privileges to afford the extra security that it
offers but also occasionally run the web browser with unrestricted
privileges so they can perform software installs when they so choose?
Some choices are shown below. The last one involving Software
Restriction Policies (SRPs) uses the power to exercise access control
within Windows itself and doesn't require the installation of any
additional security software (or can be used to augment security
software that doesn't provide the option of running the web browser
under a LUA token).

You could use the 'runas' command to specify that the web browser runs
on another account which is a limited account. That's a pain in the
ass. Everytime you use 'runas' (interactively or with a shortcut), you
will get prompted for the password of that limited account. This won't
work if that limited account has no password (it is blank) or you have
no limited accounts (i.e., they're all admin accounts).

Windows XP, and later, has its Fast User Switching (FUS) feature which
lets you stay logged in under your current account while simultaneously
logging under another account. So you could log under your limited
account to do most of your everyday tasks there including your casual
web browsing. When you need admin-level privileges on your programs,
use FUS to login and switch to your admin-level account and run your web
browser and installs over there. Window Vista's UAC (User Access
Control) eliminates having to do this switching back and forth between
limited and admin accounts; however, many users disable UAC soon after
getting acquainted with Vista because they consider it a nuisance.
Using FUS to switch between limited and admin accounts (which can remain
logged in) might be more comfortable for these users.

There are utilities that will load a program under a LUA token. The
process gets the same privileges as the token. Since the LUA token has
reduced privileges so does the process loaded under a LUA token, and so
are all child processes of that parent LUA-tokened process forced to run
under reduced privileges. An old utility that allowed you to run a
program under a LUA token was DropMyRights. An alternative is
SysInternals' psexec utility (with its -l command-line parameter). The
problem with this method is that only the program started by
DropMyRights or psexec would have its privileges reduced by running
under an LUA token. It does not handle when the program is started as a
child process of another program, like when you click on a URL in a
message in your e-mail client that loads the web browser. The shortcut
that runs DropMyRights or psexec to run the web browser under an LUA
token has no effect when the web browser is started by some other
program. You can define shortcuts that use DropMyRights or psexec to
reduce privileges on the program that they load but you can still have
instances of that program started that will run with unrestricted
privileges (i.e., they get the same privileges as the program that
loaded them which probably will be the privileges of your admin-level
account that you logged into).

There are security programs that let you run a program under reduced
privileges. For example, there is Tall Emu's Online Armor (firewall
with HIPS [Host Intrusion Protection System] which has rules to govern
what applications can load and/or obtain network connections). It has
the Run Safer option which will ensure that the program always gets
loaded under a LUA token no matter who or what started that program. So
whether you clicked on a shortcut to load the web browser or you clicked
a URL link in a message in your e-mail client, the web browser will
still run under a LUA token. Comodo's firewall (v4) has a
pseudo-sandbox feature (it has some virtualization but is not a full
sandbox, like Sandboxie). You can add a program to the "Programs in the
Sandbox" list which means they will always get sandboxed. This will run
that program in Comodo's isolated environment and also runs the program
with reduced privileges. There are problems when running programs
within a sandbox due to trying to isolate that program. Here we are
only discussing how to reduce privileges on a process to restrict what
it or any child processes started by it can do. In Comodo's sandbox,
you can disable file (and registry) virtualization and the program will
not be sandboxed but it will run under a LUA token. If you are looking
to add a firewall+HIPS security product then one that affords you to
configure a program to force it to always run under a LUA token is a
good choice. Both OA and Comodo let you quickly disable their Program
Guard or sandbox by right-click on their tray icon. That way, when you
need unrestricted (admin) privileges for the web browser, like when
getting updates from the Windows Update site, you can quickly turn off
the protection, start a new instance of the web browser to do your
thing, unload that instance of the web browser, and then re-enable the
protection.

The last method doesn't require any additional software if you are using
Windows XP, or higher. It involves using software restriction policies
which are a feature of those operating systems. In Windows Vista and
up, there is a "Basic User" protection level that can be specified in a
SRP rule which will run the specified program under a LUA token. Alas,
this policy level is available but hidden in Windows XP. To add the
"Basic User" policy level to Windows XP, run the following command to
add an entry into the registry:

reg.exe add
"HKLM\SOFTWARE\Policies\Microsoft\Windows\Safer\Co deIdentifiers" /v
"Levels" /t REG_DWORD /d 0x20000

The above line may be wrapped. It is one line that runs reg.exe
(command-line registry editor) with a whole lot of parameters. Then to
see if this policy level got added, run the group policy editor
(gpedit.msc) and navigate to the following node:

Computer Configuration -> Windows Settings -> Security Settings ->
Software Restriction Policies -> Security Levels

Note: gpedit may not be available in Home editions of Windows.

You should see the following security levels:

Disallowed: A program with this policy level cannot load.
Unrestricted: A program has all privileges of the account under which it
was loaded.
Basic User: A program runs under the reduced privileges of a limited
account.

Now you can define an SRP path rule to a program that will force that
program to be managed by one of these policy levels. The Disallowed
level can be used to keep programs from loading. You may install a
program that you want but it keeps trying to run another program that
you don't want to let run (like Quicktime that keeps trying to run
qttask.exe or RealPlayers realsched.exe program to check for updates).
To force the web browser to run under the Basic User policy level (so it
has the reduced privileges of the LUA token):

- Go under "Additional Rules" tree node.
- In the right panel listing the rules, right-click and select "New path
rule".
- Browse to the web browser's executable file (e.g., iexplore.exe).
- Select "Basic User" for the security level.
- Add a comment, like "Force web browser to run under reduced
privileges".
- Click OK.

Any currently open instances of the web browser will retain whatever
privileges they had when they loaded. Close them all. Now when you
load the web browser whether directly with a shortcut or indirectly as a
child process, like a URL link in an e-mail, the web browser will run
under the Basic User security policy which reduces privileges on that
process.

Okay, you've now choked the privileges of every instance of your web
browser but you know there are times when you need an unrestricted
instance to, say, apply updates through the web browser to Windows or to
install AX controls into the web browser. Well, remember that the SRP
policy is a *path* rule. It will apply the policy to THAT program that
you specified, not to a file in some other path. So, and using Internet
Explorer as an example, just make another copy of the web browser's
executable file that is in a different path (some, like IE, won't run if
you merely make another copy of iexplore.exe and call it another name,
like iexplore2.exe). Go to the web browser's install folder (C:\Program
Files\Internet Explorer), make a subfolder called, say, NoSRP, and copy
iexplore.exe under that new folder. The SRP policy won't apply to that
copy of the web browser's exectuable file because the path to it is
different. Then create a shortcut to that alternately pathed executable
file and use that for your unrestricted copy of the web browser.

For those that like to add 3rd party security products, some will let
you restrict the privileges on a program, like the web browser, to make
it more secure against attack as an infection vector for malware.
However, for those that don't want all the overhead and headaches of
adding more security software that produces more prompts that the user
may not understand and causes potential conflicts with use of the
programs that you are trying to protect, an SRP policy using the Basic
User security level to run the program under a LUA token that reduces
that program's privileges is just as good as logging under a limited
account and running the program there.
 
Reply With Quote
 
 
 
 
M.L.
Guest
Posts: n/a
 
      01-04-2011


>Security experts usually recommend that users log into a limited user
>account (LUA) to more securely surf the web. When logged under a LUA,
>privileges are reduced on the web browser will severely curtails the
>damage that malware can perform when the web browser is the infection
>vector into your computer.


That's why I would never use XP again. Vista/Win7 run under LUA by
default.
 
Reply With Quote
 
VanguardLH
Guest
Posts: n/a
 
      01-04-2011
M.L. wrote:

>>Security experts usually recommend that users log into a limited user
>>account (LUA) to more securely surf the web. When logged under a LUA,
>>privileges are reduced on the web browser will severely curtails the
>>damage that malware can perform when the web browser is the infection
>>vector into your computer.

>
> That's why I would never use XP again. Vista/Win7 run under LUA by
> default.


Gee, guess you missed the whol point of running ANY program under a LUA
token. Does the same thing. Ooooh, Vista does it automatically. Big
deal. Automatically means it is automatically always in your way.
Many, and I mean MANY, users disable UAC in Vista because it is a big
nuisance and always getting in your way (well, in the way of those that
need to be logging in under an admin-level account all the time). Yeah,
let's not use the features of Windows that started in version 2000 and
got polished in XP. Yeah, let's be lazy and have yet more fluff and
wizards in our face. No thanks.

Windows XP has SRPs. Vista wrapped it up pretty along with all their
other wizard and UI fluff that added no extra functionality and instead
continually gets in the way of actually USING the operating system
instead of playing with it all the time.
 
Reply With Quote
 
VanguardLH
Guest
Posts: n/a
 
      01-04-2011
Lookout wrote:

> On Tue, 4 Jan 2011 00:14:08 -0600, VanguardLH <(E-Mail Removed)> wrote:
>
>>Lookout wrote:
>>
>>> Windows XP Pro
>>> All Svc packs
>>>
>>> While using Firefox AND Yahoo chat a virus program popped up ...

>>
>>Never click on anything presented in the rogueware web page. Don't even
>>click on the Yes/Cancel links presented in a fake dialog. The clicking
>>action, even when you are trying to exit, can result in a download (but
>>then IE should be configured to alert you about the download AND trying
>>to run it after downloaded - but then users do clicking they shouldn't).

>
> I didn't. As I said IE wasn't even open at the time. I DON'T use IE.


Then why are you whining about IE which you claimed in your *subject*
was the culprit? Obviously it was Firefox or one of those marvelous
crappily coded plug-ins that got used as an infection vector into your
host. Programs can't do anything unless loaded into memory (i.e.,
running). I bet Office or OpenOffice weren't running at the time, too,
so are they also at fault for the infection?

The clicking action mentioned applies to all web browsers. Don't click
on their proffered dialogs when you hit a rogueware or malicious site.
While I gave a use of taskkill to kill all instances of IE, it can also
be used to kill all instances of Firefox, Opera, Chrome, or whatever is
your personal choice for a web browser or any other process.
 
Reply With Quote
 
VanguardLH
Guest
Posts: n/a
 
      01-04-2011
Lookout wrote:

> VanguardLH wrote:
>
>> Lookout wrote:
>>
>>> As I said IE wasn't even open at the time. I DON'T use IE.

>>
>> Then why are you whining about IE which you claimed in your
>> *subject* was the culprit? Obviously it was Firefox or one of those
>> marvelous crappily coded plug-ins that got used as an infection
>> vector into your host.

>
> Because it affected IE and NOT Mazola. I had Mozilla open. As I said
> it ONLY affected IE, and updates for MalwareBytes and
> SuperAntiSpyware. I COULD get on Usenet and IRC.


So the malware *targeted* Internet Explorer. The trojan didn't get
"through" IE. It got through by some other means and got "at" IE. I
figured when you said the trojan got through that it was through IE.
My mistake.

> Once I was able to update SupeAntiSpyware it DID find 4 trojans and
> eliminated them.


Good to know. I've played around with SuperAntispyware in the past but
always ended up uninstalling it. Maybe it's time to reconsider it as
yet another on-demand only scanner.
 
Reply With Quote
 
Bucky Breeder
Guest
Posts: n/a
 
      01-05-2011
Lookout <(E-Mail Removed)> is givin' Firefox a bad rep now:
>
> Which is why I use FireFox.


Just stay the **** off my internet, you pathetic dumbass.

HTH.

--

I AM Bucky Breeder, (*(^; in loving touch with my
"inner narcissist" and on the 'AWESOMENESS METER',
I register about two clicks better than 'TOTALLY'!

You should not view the world in terms
of things which you do - or do not - "like";
rather, you should view the world in terms
of how things "actually are", recognizing
and finding acceptance of them as such.

This would immeasurably bring *much* more
stability, peace and tranquility into your life.

I could help you with that... but...
I really just don't like you that much.

Repent! The end is near! Or, smoke 'em if you got 'em...
an-nnnn-duh... *good* "luck" - if there's an apocalypse.

(Me? I don't go anywhere without a shotgun and package of beef jerky!)

(And some breath-freshening gum... just in case I run into any pretty
white ladies who wanna have some fun before I throw them out as bait
to the flesh-eating zombies so I can escape quietly yet very quickly.)
 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
Re: Trojan got through to JUST IE and not FireFox PeeCee Computer Support 1 01-05-2011 10:31 AM
Re: Trojan got through to JUST IE and not FireFox Mike Easter Computer Support 2 01-05-2011 10:27 AM
Re: Trojan got through to JUST IE and not FireFox Meat Plow Computer Support 0 01-04-2011 03:29 PM
Re: Trojan got through to JUST IE and not FireFox richard Computer Support 0 01-03-2011 11:06 PM
New trojan spam tells you where to download trojan as "MS beta antispy" Joel Rubin Computer Support 2 03-07-2005 02:26 AM



Advertisments