Open GoogleCodeExporter opened 8 years ago
"8. Malicious Products: Don't transmit viruses, malware or any other malicious
or destructive code. We don't allow content that harms or interferes with the
operation of the networks, servers, or other infrastructure of Google or any
third-parties. However, we do allow projects that host open source malware code
for security reasons, but not binary/downloadable modules"
All the code is open source and hosted for security research. I have had no
complaints from Google staff, and am fairly certain I am well within ToS.
Please note the following quote:
"However, we do allow projects that host open source malware code for security
reasons, but not binary/downloadable modules"
All (with one or two notable exceptions where I could only pull binaries from
Kippo) the code there is open source and hosted so independent security and
malware researchers can analyse them. The idea behind it is so that AV vendors,
and normal researchers, students, security-hobbyists, etc can study the malware
used in attacks and such and understand how it works, obfustication methods
used, etc.
I must refuse to pull the project as that goes against the open source model I
use in my research. IF you find that code SPECIFICALLY hosted on this project
is being used in attacks on your network please let me know so I can try do
something about it.
AV vendors can come to me if they want the samples - same as anyone else.
Original comment by the.info...@gmail.com
on 11 Apr 2012 at 12:12
These can be used in remote file inclusion vulnerabilities as per files in SVN
can be downloaded in "raw-mode":
http://web-malware-collection.googlecode.com/svn/trunk/Bots/Perl/scane.txt
Please also note that these samples are not open source. These are just plain
text.
"Don't transmit viruses, malware or any other malicious or destructive code."
you are doing exactly that.
Original comment by he...@nerv.fi
on 20 May 2012 at 2:15
Sorry about my untimely replies, but these things are available everywhere. And
they are "open source", as the source is clearly visible to view.
However, I do see your point, and am working on an alternative. While I will
continue to make the samples available, I will do so in a less abuseable manner
- by hosting a tarball in the "downloads" section, and disallowing people from
getting them from the SVN.
Thanks for pointing out that method of abuse though, it had not crossed my
mind, adn should have been obvious.
Original comment by the.info...@gmail.com
on 10 Jun 2012 at 12:16
svn rm *
svn commit
Done. Might reset the repo properly later.
Original comment by the.info...@gmail.com
on 13 Jun 2012 at 8:53
Content still available:
http://web-malware-collection.googlecode.com/svn-history/r15/trunk/Backdoors/PHP
/b37.php
Original comment by he...@nerv.fi
on 14 Jun 2012 at 11:59
yay. a repo reset it is. "fun".
Should that take care of it?
Original comment by the.info...@gmail.com
on 14 Jun 2012 at 10:09
now, if you can still find malicious code in abuseable format, you will deserve
a medal. I have totally reset the repo (actually making it unuseable unless I
want to waste over9000 years messing with SVN).
"fun times".
The project will go on though!
Original comment by the.info...@gmail.com
on 14 Jun 2012 at 10:12
thanks for killing an important source of information make no mistakes the bag
guys can find this stuff anyware you how ever have made it more difficult to
legitimate sysadmins to obtain samples for analysis asshole!
Original comment by darkjes...@gmail.com
on 2 Aug 2012 at 12:25
Well you can ask the samples from project owner via for example encrypted email
if you are a researcher, but your attitude does not sound co-operative. I did
not kill anything. I am just making sure the wrong people does not have access
to these samples and if you say the bad guys can find the samples easily so
should you.
Original comment by he...@nerv.fi
on 2 Aug 2012 at 5:59
The samples are still available as a tarball, and I have noticed people
mirrored it on Github in a few places.
I will occasionally update with new samples as I get em, but so far it has been
"more of the same shit" in my honeypots :(
I can see Henri has a valid point - you could use the SVN URI as a wget point
for RFI attacks. The tarball is hurting no one though - unless it was to be
wgot onto a compromised host or something.
Original comment by the.info...@gmail.com
on 30 Sep 2012 at 12:04
Related discussion http://insecurety.net/?p=96
Original comment by he...@nerv.fi
on 24 Apr 2013 at 9:14
Original issue reported on code.google.com by
he...@nerv.fi
on 28 Mar 2012 at 8:58