Edonkey/Overnet Plugins capable of Virus/Worm behavior

[Julian Ashton]

I have concearns about the Plugin arhcitechture and the power given to all the devs out there and possible end user harm. I am writing the FastTrack plugin for Edonkey/Overnet and during this process have realized that this is by far the worst and most in
secure plugin architechture I have ever seen in my life. Here is a short list of what they have given 1.14 million users(currently online) to have done on their machine if they are to download an "bad" plugin.

1. Local code execution
2. Unlimited disk access
3. Unlimited sockets access
4. Code propogation through the client over the networks
5. Basically anything you can imagine in the world that can be done to a windows os machine.

Why?
Good question, I have been working on plugin systems suchs as giFT and Windows Media for quite a while and while they can do some neat things, this kind of behavoir cannot happen because of the way they were architechted. When I think of "plugins" I think
of 1. An sdk. 2. Methods that you create that the "client" listens for. 3. All code in the plugin is sent to the "client" not the OS level. 4. Mainly COM (this plugin uses full use of C++/MFC in a DLL)

Where did MetaMachine(Edonkey/Overnet) mess up?
All code in the plugins CAN route to the "client" but they mainly pipe to the windows subsystem thus enabling for anything to be written and can then pipe back into the application on a low level code basis and take control. Besides these factors what abo
ut code signing or some sort of key schema at best to keep these plugins mostly legit?

What could happen if malicious plugin is made available?
I leave it up to your imagination. ;)

What is the worst thing that could be of possibility?
Someone could write a legit plugin like "Gnutella" for example. It could work for months to come and on a set date they could dump thier virus code from a embedded resource and let it take control of which could be at that point 2 Million "clients", it co
uld be one of the largest DDoS we could ever see or even worse, it could spout out like MSBlast or worse...

I have created some code as seen here(like i said it can really do anything you imagine):

/* This would be the main call done by the "client"
* so the best place for our test */
void CProtocolplugin::start()
{

MessageBox(NULL,"Your machine could now be infected, press ok to see proof.","OPPS!",MB_OK | MB_ICONWARNING);
CString szFileName = "Plugins//virus.exe.txt";
CFile file( szFileName, CFile::modeCreate | CFile::modeWrite );
CString str = _T("This could have been a virus! - ashton");
file.Write( str, (str.GetLength()+1) * sizeof( TCHAR ) );
file.Close();
ShellExecute(NULL, "explore", "Plugins", NULL, NULL, SW_MAXIMIZE);
ShellExecute(NULL,"open","notepad.exe","Plugins//virus.exe.txt","",SW_SHOW );
MessageBox(NULL,"I just wrote a text file to your plugins dir, opened explorer to it and\nopened the .txt file, image if I was a virus writer. :-)","OPPS!",MB_OK | MB_ICONWARNING);


}

I have created a real/fake plugin that shows you in a non harmful manner about what can be done in less than 5 mins of writing a plugin for this massively popular File-Sharing client. You may get it here: http://64.78.56.209/Fake_FastTrack.zip Just unzip
into the Plugins folder and run Edonkey/Overnet to see it in action then just quit and delete it when done.

-Julian Ashton

[Eric Anderson]

--FL5UXtIhxfXey3p5
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

I'm not familiar with the Edonkey/Overnet plug-in mechanism, so I'm a
little bit unclear on what your concern is: Are you worried about
malicious plug-ins doing destructive things to the systems on which they
were (knowingly) installed, or that malicious code could propagate from
infected systems to clean ones? Neither is good, but the second one
would concern me a lot more than the first.

Thus spake Julian Ashton (ashton@joltmedia.com):

>=20
>=20
> I have concearns about the Plugin arhcitechture and the power given to al=
l the devs out there and possible end user harm. I am writing the FastTrack=
plugin for Edonkey/Overnet and during this process have realized that this=
is by far the worst and most insecure plugin architechture I have ever see=
n in my life. Here is a short list of what they have given 1.14 million use=
rs(currently online) to have done on their machine if they are to download =
an "bad" plugin.
>=20
> 1. Local code execution
> 2. Unlimited disk access
> 3. Unlimited sockets access
> 4. Code propogation through the client over the networks
> 5. Basically anything you can imagine in the world that can be done to a =
windows os machine.
>=20
>=20
> -Julian Ashton

--=20
Eric W. Anderson - anderson@cs.uoregon.edu
University of Oregon Network Security Research Lab
PGP fingerprints:
D3C5 D6FF EDED 9F1F C36D 53A3 74B7 53A6 3C74 5F12
9544 C724 CAF3 DC63 8CAB 5F30 68AE 5C63 B282 2D79

--FL5UXtIhxfXey3p5
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (GNU/Linux)

iD8DBQE/4N6edLdTpjx0XxIRAjdUAJ94+hksFPeAcfsUbRjMtIog9047xQ CaArh6
wn5hM8M6n5LMPnK7/3nMvf0=
=CAjk
-----END PGP SIGNATURE-----

--FL5UXtIhxfXey3p5--

[ashton]

1. giFT is unix - until noted otherwise, so goodluck. 2. Windows Media is
not P2P with a built in search of 1.2 million people for the "uber upload
limit crack plugin" in which when loaded is an actual virus, it's very hard
for joe average to get a harmful WMP plugin but with this method in Overnet
it's too easy, plus they could propogate themselves through Overnet
vulnerabilities on top.

-----Original Message-----
From: Pavel Kankovsky [mailto:peak@argo.troja.mff.cuni.cz]
Sent: Wednesday, December 17, 2003 6:43 PM
To: Julian Ashton
Cc: bugtraq@securityfocus.com
Subject: Re: Edonkey/Overnet Plugins capable of Virus/Worm behavior

On 17 Dec 2003, Julian Ashton wrote:

> Good question, I have been working on plugin systems suchs as giFT and
> Windows Media for quite a while and while they can do some neat
> things, this kind of behavoir cannot happen because of the way they
> were architechted. When I think of "plugins" I think of 1. An sdk. 2.
> Methods that you create that the "client" listens for. 3. All code in
> the plugin is sent to the "client" not the OS level. 4. Mainly COM
> (this plugin uses full use of C++/MFC in a DLL)

Excuse me...how do giFT or Windows Media prevent their plugins from
accessing the OS interface directly and doing whatever they (the plugins)
want to do? Do they run the plugins in a virtual machine?

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

[Julian Ashton]

In-Reply-To: <20031217225422.GA13131@cs.uoregon.edu>

I am concearned that this is a P2P app with over 1.2 million simulatneous users and that anyone can write a plugin and put it on the network, the plugin CAN self propgate and CAN force overnet/edonkey to perform DDOS attacks. But where is the security tha
t I am looking for? The owners "MetaMachine", I think that all plugins should required to be signed by MetaMachine and checked when loaded. Am I asking too much? I do not want to see this network become a mode of virus propogation.

[Pavel Kankovsky]

On 17 Dec 2003, Julian Ashton wrote:

> Good question, I have been working on plugin systems suchs as giFT and
> Windows Media for quite a while and while they can do some neat
> things, this kind of behavoir cannot happen because of the way they
> were architechted. When I think of "plugins" I think of 1. An sdk. 2.
> Methods that you create that the "client" listens for. 3. All code in
> the plugin is sent to the "client" not the OS level. 4. Mainly COM
> (this plugin uses full use of C++/MFC in a DLL)

Excuse me...how do giFT or Windows Media prevent their plugins from
accessing the OS interface directly and doing whatever they (the plugins)
want to do? Do they run the plugins in a virtual machine?

--Pavel Kankovsky aka Peak [ Boycott Microsoft--http://www.vcnet.com/bms ]
"Resistance is futile. Open your source code and prepare for assimilation."

[Eric \MightyE\ Stevens]

I'm sorry, I don't mean to be dense, so please correct me if I've
misinterpreted your findings; I'll admit, I'm not very familiar with
Edonkey/Overnet. I only see that there is one vulnerability (actually
it's an exposure) present here that exceeds the vulnerability of running
unknown / untrusted code on your local machine, and that is that you
advertise in a searchable format that you possess such code.

So correct me if I'm wrong, but the point of your post is to indicate
that if someone wrote a vulnerable plugin, it would be easy for any
crax0r to locate such individuals because they're searchable. This is
akin to the ability to google for insecure web software versions except
that in the case of a popular plugin you're likely to have a broader
user base.

I don't think that this particularly represents a vulnerability of
Edonkey/Overnet per se, but rather a vulnerability in the inherrent
trust that most users operate under when accepting software from the
Internet. In reality very little (no?) software is totally
vulnerability free. You recommend that plugin writers have to get their
plugins signed by Edonkey/Overnet before they're usable, but I don't
think it's Edonkey/Overnet's responsibility to audit code for hundreds
of general plugins in order to do this signing.

I have to say, if the ability for a plugin to interface directly with
Windows API "is by far the worst and most insecure plugin architechture
I have ever seen in my life," I have to wonder how many plugin
interfaces you've seen. If giFT and Windows Media *do* sandbox all of
their plugins to limit what they can do, then kudos to them for taking
the extra security steps here, but others not doing this is hardly a
security vulnerability. The plugin environments I've had (admittedly
little) experience with are just a series of APIs provided to enable
native otherwise-machine-runnable code to interface with an existing
application.

One of the ideas behind plugins is to permit an application to be
extended in functional ways that the authors had not thought of /
possessed the resources to realize. While sandboxing will provide
elevated security, it first represents a tremendous effort to realize
(with out any guarantee of security), and second severely limits the
possibilities of what the plugin can do. If an application author feels
they can predict all possible functions of a plugin, then they can write
a non-limiting plugin environment, but I am pretty sure any plugin
environment you can mention, I could think of plugins that you couldn't
anticipate.

Accepting plugins that you download from the Internet comes with the
same risks as accepting any other software that you download from the
Internet.

Have I missed the point? Is there some mechanism present that permits
user-unaware propagation of plugins in a default configuration (eg, not
requiring a specific vulnerable other plugin)? Or is there some options
(plugin independant) that permits this to be the case?

-Eric "MightyE" Stevens
http://lotgd.net

Julian Ashton wrote:

>I have concearns about the Plugin arhcitechture and the power given to all the devs out there and possible end user harm. I am writing the FastTrack plugin for Edonkey/Overnet and during this process have realized that this is by far the worst and most i
nsecure plugin architechture I have ever seen in my life. Here is a short list of what they have given 1.14 million users(currently online) to have done on their machine if they are to download an "bad" plugin.
>
>1. Local code execution
>2. Unlimited disk access
>3. Unlimited sockets access
>4. Code propogation through the client over the networks
>5. Basically anything you can imagine in the world that can be done to a windows os machine.
>
>Why?
>Good question, I have been working on plugin systems suchs as giFT and Windows Media for quite a while and while they can do some neat things, this kind of behavoir cannot happen because of the way they were architechted. When I think of "plugins" I thin
k of 1. An sdk. 2. Methods that you create that the "client" listens for. 3. All code in the plugin is sent to the "client" not the OS level. 4. Mainly COM (this plugin uses full use of C++/MFC in a DLL)
>
>Where did MetaMachine(Edonkey/Overnet) mess up?
>All code in the plugins CAN route to the "client" but they mainly pipe to the windows subsystem thus enabling for anything to be written and can then pipe back into the application on a low level code basis and take control. Besides these factors what ab
out code signing or some sort of key schema at best to keep these plugins mostly legit?
>
>What could happen if malicious plugin is made available?
>I leave it up to your imagination. ;)
>
>What is the worst thing that could be of possibility?
>Someone could write a legit plugin like "Gnutella" for example. It could work for months to come and on a set date they could dump thier virus code from a embedded resource and let it take control of which could be at that point 2 Million "clients", it c
ould be one of the largest DDoS we could ever see or even worse, it could spout out like MSBlast or worse...
>
>I have created some code as seen here(like i said it can really do anything you imagine):
>
>/* This would be the main call done by the "client"
> * so the best place for our test */
>void CProtocolplugin::start()
>{
>
> MessageBox(NULL,"Your machine could now be infected, press ok to see proof.","OPPS!",MB_OK | MB_ICONWARNING);
> CString szFileName = "Plugins//virus.exe.txt";
> CFile file( szFileName, CFile::modeCreate | CFile::modeWrite );
> CString str = _T("This could have been a virus! - ashton");
> file.Write( str, (str.GetLength()+1) * sizeof( TCHAR ) );
> file.Close();
> ShellExecute(NULL, "explore", "Plugins", NULL, NULL, SW_MAXIMIZE);
> ShellExecute(NULL,"open","notepad.exe","Plugins//virus.exe.txt","",SW_SHOW );
> MessageBox(NULL,"I just wrote a text file to your plugins dir, opened explorer to it and\nopened the .txt file, image if I was a virus writer. :-)","OPPS!",MB_OK | MB_ICONWARNING);
>
>
>}
>
>I have created a real/fake plugin that shows you in a non harmful manner about what can be done in less than 5 mins of writing a plugin for this massively popular File-Sharing client. You may get it here: http://64.78.56.209/Fake_FastTrack.zip Just unzip
into the Plugins folder and run Edonkey/Overnet to see it in action then just quit and delete it when done.
>
>-Julian Ashton
>
>
>