Note this is not a CVE since it's not a NetBeans vulnerability. Executing any build will run with the local user privileges on any popular IDE and injecting something dubious in a build is trivial.
Still, I think GitHub could have approached the Apache security team so the NetBeans PMC has a reply to this. It would be trivial to push a check for that cache.dat file but it's not the role of the IDE to play at being an antivirus. --emi sâm., 30 mai 2020, 14:03 Geertjan Wielenga <geert...@apache.org> a scris: > > It seems to me like we should put out a blog entry with some response to > this. Just so that we have a central point to refer to when people ask > about this. > > However, I have no idea what that blog entry should say, beyond “if > someone wants to do so, they can inject malware into the build process of > software, here’s an example of how they can do that”, and then point to > that report. > > Gj > > On Sat, 30 May 2020 at 12:08, Emma Atkinson <emma.atkins...@gmail.com> > wrote: > >> Should someone from the Apache Netbeans governing team, approach >> Microsoft for information on this matter? >> >> I would have thought Microsoft GitHub would welcome any approach that >> might go some way toward tackling the problem. Knowing details should >> enable the Netbeans and NetbeansIDE communities to help. It would also be >> good for the public to know Apache Netbeans takes these matters as >> seriously as Oracle would have done. Be on the front foot. >> >> This might be a matter of reducing risk rather than eliminating a >> vulnerability. Any fix may not involve much effort. Perhaps a written or >> updated guide might be all that is needed. If the contaminated accounts >> belong to computer science students, perhaps some changes to Apache >> Netbeans IDE defaults, or added warnings would help users avoid inadvertent >> contamination of their code or build environments from untrusted origins. A >> general lesson in good practice perhaps. >> >> Emma >> >> >> On Sat, 30 May 2020, 09:32 Emilian Bold, <emilian.b...@gmail.com> wrote: >> >>> I'm leaning towards this being a student project honestly. Why would a >>> company developing a legacy project grab random unknown Ant-based >>> projects from GitHub? >>> >>> But NetBeans is used a lot for teaching and I suspect teachers don't >>> introduce Maven / Gradle since they are more complex and they use the >>> default Ant-based build system. >>> >>> So, if a smart student wants to troll his fellow students it does >>> something like this. >>> >>> Note that GitHub has the full logs of who uploaded, downloaded, >>> visited and cloned those 26 projects but made no remarks about them. I >>> think those logs would be highly informative as to source and the >>> target domain / country. My money is on students from India / China / >>> Greece / Brazil. >>> >>> --emi >>> >>> On Fri, May 29, 2020 at 11:50 PM Alan <netbeans.5zc...@ambitonline.com> >>> wrote: >>> > >>> > 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> >>> 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> 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> >>> 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> >>> 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> >>> 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 >>> >> For additional commands, e-mail: 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 >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: users-unsubscr...@netbeans.apache.org >>> For additional commands, e-mail: users-h...@netbeans.apache.org >>> >>> For further information about the NetBeans mailing lists, visit: >>> https://cwiki.apache.org/confluence/display/NETBEANS/Mailing+lists >>> >>>
