The odds that a virus scanner would have a pattern for something like
this are very low indeed, so in this specific case I doubt it would make
a difference. However, excluding paths for any reason leaves an aperture
open that could be exploited.
The targeted attacks I've seen are amazingly specific. For example,
someone profiled a customer site looking for the queries with the
slowest response time, then launched requests against those pages at a
rate low enough to not trigger DDoS protection on the network firewall,
but to bring the site down anyway.
This malware has the hallmarks of such a specific attack. Scan the end
product for open source components, then infect the components, get in,
get the code, go away. Not something your general antivirus software is
ever going to even notice.
On 2020-05-29 16:32, Juan Algaba wrote:
I wonder if excluding netbeans from antivirus scanning (for
performance reasons), but not the project folders, make you more at
risk to something like this?
On Fri, May 29, 2020 at 12:40 PM Alan <netbeans.5zc...@ambitonline.com
<mailto:netbeans.5zc...@ambitonline.com>> wrote:
The malware is oddly focused. I suspect a specific group was being
targeted. If eventually GitHub releases the project names that
might provide a clue.
On 2020-05-29 15:30, Emilian Bold wrote:
so I guess this is all just about me. :-)
Hehe.
Still, they worked too much to target Ant and NetBeans. I think the
Gradle wrapper is a much easier target and developers will run
./gradlew without a 2nd tought.
--emi
On Fri, May 29, 2020 at 10:25 PM Geertjan Wielenga<geert...@apache.org>
<mailto:geert...@apache.org> wrote:
Sure, those are simply Ant files.
I also wonder about the 26 open source projects they refer to on GitHub,
without naming them, where this problem was encountered. I have about that
number of NetBeans projects in my GitHub repo, so I guess this is all just
about me. :-)
Gj
On Fri, 29 May 2020 at 21:22, Scott Palmer<swpal...@gmail.com>
<mailto:swpal...@gmail.com> wrote:
The malware explicitly targets NetBeans:
The malware is capable of identifying the NetBeans project files and
embedding malicious payload both in project files and build JAR files. Below is
a high -evel description of the Octopus Scanner operation:
• Identify user's NetBeans directory
• Enumerate all projects in the NetBeans directory
• Copy malicious payload cache.dat to nbproject/cache.dat
• Modify the nbproject/build-impl.xml file to make sure the malicious
payload is executed every time NetBeans project is build
• If the malicious payload is an instance of the Octopus Scanner itself the
newly built JAR file is also infected.
Though they did also mention:
"If malware developers took the time to implement this malware specifically for
NetBeans, it means that it could either be a targeted attack, or they may already have
implemented the malware for build systems such as Make, MsBuild, Gradle and others as
well and it may be spreading unnoticed," GitHub added.
I’m not sure if there is any sort of sanity check NB can do to the
cache.dat file to help prevent this.
Scott
On May 29, 2020, at 3:16 PM, Geertjan Wielenga<geert...@apache.org>
<mailto:geert...@apache.org> wrote:
It seems to be saying that a build system that uses Apache Ant can be
poisoned by malware. That probably is equally true for Gradle and Apache Maven
— so I don’t understand why they’re picking on Ant.
Gj
On Fri, 29 May 2020 at 21:09, Peter Steele<steeleh...@gmail.com>
<mailto:steeleh...@gmail.com> wrote:
Hi
Saw this
https://www.zdnet.com/article/github-warns-java-developers-of-new-malware-poisoning-netbeans-projects/
Do we know anything more about this?
---------------------------------------------------------------------
To unsubscribe, e-mail:users-unsubscr...@netbeans.apache.org
<mailto:users-unsubscr...@netbeans.apache.org>
For additional commands, e-mail:users-h...@netbeans.apache.org
<mailto:users-h...@netbeans.apache.org>
For further information about the NetBeans mailing lists, visit:
https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists
--
-Juan Algaba
