The amount of time cyber criminals intruders are spending inside victims’ networks is increasing, providing them with the ability to carry out higher complexity campaigns and more damaging cyber attacks.  According to analysis by cybersecurity researchers at Sophos, who examined incidents targeting organisations around the world and across a wide range of industry sectors, the […] More

Last week, some University of Minnesota (UMN) security researchers kicked a hornet nest, when it was revealed that they’d tried to insert deliberately buggy patches into Linux. Greg Kroah-Hartman, the well-respected Linux kernel maintainer for the Linux stable branch, responded by banning not only them but any UMN-connected developers from contributing to the Linux kernel. Now, the researchers have sort of, kind of, apologized for their mistakes: “We sincerely apologize for any harm our research group did to the Linux kernel community.” 

Open Source

The apology started well enough. But, Kangjie Lu,  the assistant professor in the Computer Science & Engineering Department of the UMN in charge of the product, and graduate student researchers, Qiushi Wu, and Aditya Pakki continued: Our goal was to identify issues with the patching process and ways to address them, and we are very sorry that the method used in the “hypocrite commits” paper was inappropriate. As many observers have pointed out to us, we made a mistake by not finding a way to consult with the community and obtain permission before running this study; we did that because we knew we could not ask the maintainers of Linux for permission, or they would be on the lookout for the hypocrite patches. While our goal was to improve the security of Linux, we now understand that it was hurtful to the community to make it a subject of our research and to waste its effort reviewing these patches without its knowledge or permission. You think? This is simply not how Red Team testing is done. At least some of the leaders of the targeted “ethical hacking attack” are made aware that an attack is coming. Otherwise, there’s no real difference between what these researchers did and ordinary, run-of-the-mill criminal hacking.  They continued, “We just want you to know that we would never intentionally hurt the Linux kernel community and never introduce security vulnerabilities. Our work was conducted with the best of intentions and is all about finding and fixing security vulnerabilities.” They then explained, “The “hypocrite commits” work was carried out in August 2020; it aimed to improve the security of the patching process in Linux. As part of the project, we studied potential issues with the patching process of Linux, including causes of the issues and suggestions for addressing them.”  And, in any case, “This work did not introduce vulnerabilities into the Linux code. The three incorrect patches were discussed and stopped during exchanges in a Linux message board, and never committed to the code. We reported the findings and our conclusions (excluding the incorrect patches) of the work to the Linux community before paper submission, collected their feedback, and included them in the paper. [“On the Feasibility of Stealthily Introducing Vulnerabilities in Open-Source Software via Hypocrite Commits”]. The researchers continued that: * All the other 190 patches being reverted and re-evaluated were submitted as part of other projects and as a service to the community; they are not related to the “hypocrite commits” paper. * These 190 patches were in response to real bugs in the code and all correct–as far as we can discern–when we submitted them. * We understand the desire of the community to gain access to and examine the three incorrect patches. Doing so would reveal the identity of members of the community who responded to these patches on the message board. Therefore, we are working to obtain their consent before revealing these patches.

What is this message board? We don’t know. It appears to not be one of the many official Linux developer mailing lists, nor the main Linux mailing list: The Linux kernel mailing list (LKML). Their apology went awry though in their last point:  * Our recent patches in April 2021 are not part of the “hypocrite commits” paper either. We had been conducting a new project that aims to automatically identify bugs introduced by other patches (not from us). Our patches were prepared and submitted to fix the identified bugs to follow the rules of Responsible Disclosure, and we are happy to share details of this newer project with the Linux community. Kroah-Hartman didn’t see these recent patches as being in the least bit valuable or even trustworthy. As he wrote about those April 2021 patches: You, and your group, have publicly admitted to sending known-buggy patches to see how the kernel community would react to them and published a paper based on that work. Now you submit a new series of obviously incorrect patches again, so what am I supposed to think of such a thing? They obviously were _NOT_ created by a static analysis tool that is of any intelligence, as they all are the result of totally different patterns and all of which are obviously not even fixing anything at all. So what am I supposed to think here, other than that you and your group are continuing to experiment on the kernel community developers by sending such nonsense patches? When submitting patches created by a tool, everyone who does so submits them with wording like “found by tool XXX, we are not sure if this is correct or not, please advise.” which is NOT what you did here at all. You were not asking for help, you were claiming that these were legitimate fixes, which you KNEW to be incorrect. A few minutes with anyone with the semblance of knowledge of C can see that your submissions do NOT do anything at all, so to think that a tool created them, and then that you thought they were a valid “fix” is totally negligent on your part, not ours.  You are the one at fault, it is not our job to be the test subjects of a tool you create. Our community welcomes developers who wish to help and enhance Linux. That is NOT what you are attempting to do here, so please do not try to frame it that way. Our community does not appreciate being experimented on, and being “tested” by submitting known patches that are either do nothing on purpose or introduce bugs on purpose.  If you wish to do work like this, I suggest you find a different community to run your experiments on, you are not welcome here. As for their apology and request to “rebuild the relationship with the Linux Foundation and the Linux community from a place of humility to create a foundation from which, we hope, we can once again contribute to our shared goal of improving the quality and security of Linux software.” Kroah-Hartman simply stated:  As you know, the Linux Foundation and the Linux Foundation’s Technical Advisory Board submitted a letter on Friday to your University outlining the specific actions which need to happen in order for your group, and your University, to be able to work to regain the trust of the Linux kernel community. Until those actions are taken, we do not have anything further to discuss about this issue.What are these actions? We don’t know. I’ve asked the appropriate people to comment on the Linux community’s demands. In the meantime, as for the code itself, Kroah-Hartman declared: “Because of this [issue], all submissions from this group must be reverted from the kernel tree and will need to be re-reviewed again to determine if they actually are a valid fix. Until that work is complete, remove this change to ensure that no problems are being introduced into the codebase.” Kees Cook, Google Linux Kernel Engineer and member of The Technical Advisory Board wrote the “Board is taking a look at the history of UMN’s contributions and their associated research projects. At present, it seems the vast majority of patches have been in good faith, but we’re continuing to review the work.” On Twitter, Cook added, “I spent a fair bit of time today going through each of the recent UMN research papers and mapping them to commits. They appear to all be in good faith. There are a small handful of mistakes that got later fixes, but given the volume of commits, that’s expected.” As for UMN, Department of Computer Science and Engineering Mats Heimdahl, Department Head, and Loren Terveen, Associate Department Head, issued a statement in which they stated they’d learned on April 21st, only after Kroah-Hartman brought the matter to the developer world’s attention. They added that they’d learned “about the details of research being conducted by one of its faculty members and graduate students into the security of the Linux Kernel. The research method used raised serious concerns in the Linux Kernel community and, as of today, this has resulted in the University being banned from contributing to the Linux Kernel.”The leaders continued, “We take this situation extremely seriously. We have immediately suspended this line of research. We will investigate the research method and the process by which this research method was approved, determine appropriate remedial action, and safeguard against future issues if needed. We will report our findings back to the community as soon as practical.”Looking from above, Linux creator Linus Torvalds is reported to have said, “I don’t think it has been a huge deal _technically_, but people are pissed off, and it’s obviously a breach of trust.” Stay tuned. While there appear to be no serious security problems as a result of the UMN blunders, trust lost is not easily regained. And, in the Linux kernel community, where trust is everything, that’s no small matter. Related Stories: More

Maria Diaz/ZDNETFollow ZDNET: Add us as a preferred source More

Employees planning to leave their jobs are involved in 60% of insider cybersecurity incidents and data leaks, new research suggests. According to the Securonix 2020 Insider Threat Report, published on Wednesday, “flight risk” employees, generally deemed to be individuals on the verge of resigning or otherwise leaving a job, often change their behavioral patterns from […] More

Image: Zscaler

special feature

Securing Your Mobile Enterprise
Mobile devices continue their march toward becoming powerful productivity machines. But they are also major security risks if they aren’t managed properly. We look at the latest wisdom and best practices for securing the mobile workforce.
Read More

Google has removed this week 17 Android applications from the official Play Store. The 17 apps, spotted by security researchers from Zscaler, were infected with the Joker (aka Bread) malware.
“This spyware is designed to steal SMS messages, contact lists, and device information, along with silently signing up the victim for premium wireless application protocol (WAP) services,” Zscaler security researcher Viral Gandhi said this week.
The 17 malicious apps were uploaded on the Play Store this month and didn’t get a chance to gain a following, having been downloaded more than 120,000 times before being detected.
The names of the 17 apps were:
All Good PDF Scanner
Mint Leaf Message-Your Private Message
Unique Keyboard – Fancy Fonts & Free Emoticons
Tangram App Lock
Direct Messenger
Private SMS
One Sentence Translator – Multifunctional Translator
Style Photo Collage
Meticulous Scanner
Desire Translate
Talent Photo Editor – Blur focus
Care Message
Part Message
Paper Doc Scanner
Blue Scanner
Hummingbird PDF Converter – Photo to PDF
All Good PDF Scanner
Following its internal procedures, Google removed the apps from the Play Store, used the Play Protect service to disable the apps on infected devices, but users still need to manually intervene and remove the apps from their devices.
Joker is the Play Store’s bane
But this recent takedown also marks the third such action from Google’s security team against a batch of Joker-infected apps over the past few months.
Google removed six such apps at the start of the month after they’ve been spotted and reported by security researchers from Pradeo.
Before that, in July, Google removed another batch of Joker-infected apps discovered by security researchers from Anquanke. This batch had been active since March and had managed to infect millions of devices.
The way these infected apps usually manage to sneak their way past Google’s defenses and reach the Play Store is through a technique called “droppers,” where the victim’s device is infected in a multi-stage process.
The technique is quite simple, but hard to defend against, from Google’s perspective.
Malware authors begin by cloning the functionality of a legitimate app and uploading it on the Play Store. This app is fully functional, requests access to dangerous permissions, but also doesn’t perform any malicious actions when it’s first run.
Because the malicious actions are usually delayed by hours or days, Google’s security scans don’t pick up the malicious code, and Google usually allows the app to be listed on the Play Store.
But once on a user’s device, the app eventually downloads and “drops” (hence the name droppers, or loaders) other components or apps on the device that contain the Joker malware or other malware strains.
The Joker family, which Google tracks internally as Bread, has been one of the most ardent users of the dropper technique. This, in turn, has allowed Joker to make it on the Play Store —the Holy Grail of most malware operations— more than many other malware groups.
In January, Google published a blog post where it described Joker as one of the most persistent and advanced threats it has dealt with in the past years. Google said that its security teams had removed more than 1,700 apps from the Play Store since 2017.
But Joker is far more widespread than that, being also found in apps uploaded on third-party Android app stores as well.
All in all, Anquanke said it detected more than 13,000 Joker samples since the malware was first discovered in December 2016.
Protecting against Joker is hard, but if users show some caution when installing apps with broad permissions, they can avoid getting infected.
In other Android security news
Bitdefender reported a batch of malicious apps to Google’s security team. Some of these apps are still available on the Play Store. Bitdefender didn’t reveal the name of the apps, but only the names of the developer accounts from which they were uploaded. Users who have installed apps from these developers should remove them right away.
Nouvette
Piastos 
Progster 
imirova91 
StokeGroove 
VolkavStune 
ThreatFabric also published a report about the demise of the Cerberus malware and the rise of the Alien malware, which contains features to steal credentials for 226 applications. More