Are the WMF viruses infecting the AD networks?

  • Thread starter Thread starter edavid3001
  • Start date Start date
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

http://www.acmenews.com/wmf.html


not say for 100% positive, due to legal liability reasons. But it sure
does look like they have.

If you don't trust me - wget the document - as it's mostly in plain
text.

If they bothered to report the abuse to paypopup.com it would have been
dealt with three days ago. The link should be offline sortly; it wasn't
difficult.


Adam Piggott,
Proprietor,
Proactive Services (Computing)
http://www.proactiveservices.co.uk/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDvEwn7uRVdtPsXDkRAhjdAJ4zvNPd/TW1UDm21drtLiD0P41GDQCgiTJi
5G+PTZcUhB/UcSbvAAwAj3g=
=K5Kj
-----END PGP SIGNATURE-----
 
On that special day, , ([email protected]) said...

It just had to happen. Didn't I mention the Falk ad incident some time
ago?

Sorry, this had been in a German newsgroup. But if you google for
TheRegister, Falk AG, and trojan, you'll find the reference.

http://www.theregister.co.uk/2004/11/21/register_adserver_attack/

In this case, the load balancer for the advertisment servers was hacked
to include a 13th one, that wasn't owned by Falk. This method was quite
effective, and so it is no wonder that it is used again.


Gabriele Neukam

(e-mail address removed)
 
If they bothered to report the abuse to paypopup.com...

The abuse was reported to Paypop. I reported it. No ill will against
Paypop. Any service that allows images could be a distro vector. What
about all these image sharing sites? A few protect us - but not all.
Any link exchange could possibly be a vector.

We have many folks here working long shifts trying to keep ahead of
this issue. While Microsoft doesn't have a patch, there are things we
are doing such as at the gateway.

Though not on our network, we have seen infections from this. Our
employees home machines, for example.

Edwin.
 
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

The abuse was reported to Paypop. I reported it. No ill will against
Paypop.

I'm not so sure about that - I spoke to them twice using their "live chat"
service and the first time was told it would be pulled soon and the second
time I couldn't get my point across. They're still forwarding to the
exploit code site! Can't help some I suppose.

I quite agree with you about link exchanges being a vector, which is why I
make efforts to filter them completely. The whole point of only browsing
safe web sites is taken away when they get content from those who are not
trusted! As Gabriele has mentioned elsewhere, Falk AG suffered for a short
while as their systems were duped to serve viruses.

I'm just glad I (and my some of my customers) have got Privoxy :-)

Cheers
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)

iD8DBQFDvaKB7uRVdtPsXDkRAoftAKCI2JI+I/usmRQ9d/kS5q9rTRgIzwCfRKQv
U/K29lNc38/Nq2s4n1l0/gU=
=majd
-----END PGP SIGNATURE-----
 
http://www.acmenews.com/wmf.html


not say for 100% positive, due to legal liability reasons. But it sure
does look like they have.

If you don't trust me - wget the document - as it's mostly in plain
text.

That's still not necessarily safe.

I have seen reports that even just downloading the file with wget could
result in a user being infected. The reason is because anyone with the
Google Desktop installed will have it try to index all files and the
moment that the file is downloaded and Google Desktop attempts to index
it ... ZAP! ... the user's computer is infected.

http://www.f-secure.com/weblog/archives/archive-122005.html

[snip]
: iframecash - don't visit the site We got several questions on our note
: on Google Desktop yesterday. Bottom line is that if an image file with
: the exploit ends up to your hard drive, Google Desktop will try to
: index it and will execute the exploit in the process. There are
: several ways such a file could end up to the local drive. And this
: indexing-will-execute problem might happen with other desktop search
: engines too.
[snip]
: Do note that it's really easy to get burned by this exploit if you're
: analysing it under Windows. All you need to do is to access an
: infected web site with IE or view a folder with infected files with
: the Windows Explorer.
:
: You can get burned even while working in a DOS box! This happened on
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: one of our test machines where we simply used the WGET command-line
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: tool to download a malicious WMF file. That's it, it was enough to
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
: download the file. So how on earth did it have a chance to execute?
^^^^^^^^^^^^^^^^^^
: Google desktop
: The test machine had Google Desktop installed. It seems that Google
: Desktop creates an index of the metadata of all images too, and it
: issues an API call to the vulnerable Windows component SHIMGVW.DLL to
: extract this info. This is enough to invoke the exploit and infect the
: machine. This all happens in realtime as Google Desktop contains a
: file system filter and will index new files in realtime.
:
: So, be careful out there. And disable indexing of media files (or get
: rid of Google Desktop) if you're handling infected files under
: Windows.
[snip]
 
Yes, you are correct. Wow. If you can't be safe using WGET, how in
the world can you be safe? It's an HTML document and not a WMF file.
Does that make a difference?
 
Yes, you are correct. Wow. If you can't be safe using WGET, how in
the world can you be safe? It's an HTML document and not a WMF file.
Does that make a difference?

The problem is not wget, it's the Google Desktop indexer when it sees
a bad WMF.
 
Back
Top