> "even if they've been a malicious actor the whole time"
That is a sound argument, even if integrity of the package was to check out (if npm tracks this internally at all).
Better to adopt a PyPI-style approach of temporarily "quarantining" packages while investigating allegations of malware for big-scale projects. Instead npm pulled the plug outright stating: "This package contained malicious code and was removed from the registry..." (generic placeholder page), which is inaccurate and likely to cause panic.
https://www.npmjs.com/package/stylus
Why not instead remove 'panya' as a maintainer from legitimate packages that were unaffected? No recent or malicious versions of Stylus have been published (which generally is the case during a hijack) and no evidence that any were altered. Stylus is relied upon by several popular frameworks including Angular 12. Admins should have at least checked this before pressing the kill switch.
"The biometric residence permit is proof of the holder’s right to stay, work or study in the UK. It can also be used as a form of identification (for example, if they wish to open a bank account in the UK).
https://assets.publishing.service.gov.uk/government/uploads/...
Good point, rather interesting they state "in all our online journeys," rather than in-person.
Anytime I've had to verify identity online for bank account opening, it entailed taking a photo of my ID which then goes through automated ID checks via Jumio or similar APIs.
I wouldn't call it a "not valid form of ID," when you can use them to board domestic flights, prove your age at establishments, and practically use it as an ID where they'd otherwise accept a driving license for ID.
While there is minimal or no passport control within the CTA, for example when travelling between UK and Ireland, the expectation is that the passenger is a citizen of a country whose nationals would not normally require a visa to enter either.
This alone may not be sufficiently proven by an ID document like driving license, and some airlines will only accept passport for travel.
Having a long term residency visa in the UK, but an Indian passport for example, would not automatically qualify you for travel to Ireland without a separate visa, although lax checks within the CTA may, in theory, let you travel if no one looks hard enough and should an airline be satisfied with your UK driving licence alone (and assume you're either an Irish or British citizen).
The requirment is further complicated by the fact that some third country nationals holding either a used and valid UK or Irish short term (tourist) visa can travel to either countries without issues due to the British-Irish Visa Scheme/treaty, but the same courtesy wouldn't apply to a third country national with a (long term) UK BRP - they'd need a separate visa for Ireland.
Border checks or lack thereof in the CTA are a rather interesting subject matter.
The author here. The name eFile(.)com is bound to confuse some readers who may mistake it for IRS' e-file system/API. Probably why the company chose that brand name (SEO or whatever). IRS-authorised software providers (who need to apply and get certified https://www.irs.gov/e-file-providers/become-an-authorized-e-... ) include those who can have taxpayers use their software to e-file returns to the IRS. These also include Intuit's TurboTax.
Anyway, there's that and confusing domain names likes like e-file(.com) that have got nothing to do with the concerned efile(.com) or the IRS, hence that note.
Probable explanation for the mysterious hacks on Xfinity accounts despite having 2FA enabled:
2FA bypass allegedly circulating privately
"A researcher has told BleepingComputer that the attacks are being conducted through credential stuffing attacks to determine the login credentials for Xfinity attacks.
Once they gain access to the account and are prompted to enter their 2FA code, the attackers allegedly use a privately circulated OTP bypass for the Xfinity site that allows them to forge successful 2FA verification requests."
Same thought here. The domain appears to be associated with Ningbo Sunning Software, a Chinese vendor and likely a Mediatek partner than anything Android.
This, as others have pointed out via tweets and Tutanota themselves acknowledging the technicality on Reddit, is why I couldn't report on it (we received the blog from them too) and am inclined to believe this is sensationalized.
Microsoft support can do better, no denying, but to use words like "blocked" and "anti-competitive practice" when a technical issue like this may apply to other domains, not just Tutanota, seems hyperbole.
Very true, the left-pad incident from 2016 may have seemed like a one off occurrence but we see protestware revived this year.
1. colors/faker followed the Log4j debacle and was more about corporations using open source heavily but not giving back enough to support the developers so the dev threw in the towel. Applications using 'colors' began freezing (entered a DoS condition) due to an infinite loop introduced by the developer in the code.
2. But with node-ipc, the self-sabotage turned destructive with the package actively deleting files on detecting a Russian/Belarusian host IP
3. event-source-polyfill, styled-components, etc. have adopted more a more "peaceful protest" approach by expressing the maintainer's views condemning the Russian war, but without engaging in outright destructive activity.
Thus far the trends have been about open source and the ongoing war.
But developers have discovered a new avenue of their creative expression (open source) which no longer limits them to simply coding the intended application functionality. And so, the questions that arise are, what will the next protest be about and if we are prepared for it?
You're welcome! If you look at "A Timeline of SSC Attacks" compiled and periodically updated by us, the trend is getting worse than better. To be blunt, the increased volume of these unwanted packages (whether research PoCs or malicious) in recent weeks can be and has been infuriating even for us to keep up with.
Whereas, previously only typosquatting or malware published to OSS repos might have been the primary concern, the recurring incidents today have diversified in both their type and quantity.
We now have to dedicate more time and resources to analyzing malicious packages that we'd have otherwise spent on hunting for zero-days or vulnerability research activities. These packages keep multiplying and it's become a whack-a-mole situation: every other day we report malware to the OSS repos, these get taken down, and the threat actor repeats the attack with slight variations a few days later. Additionally, copycat attacks follow, further increasing the number of malware incidents.
For example, other than typosquatting attacks, between last year and now we saw attackers hijacking legitimate libraries (ua-parser-js, coa, rc) or publishing tens of thousands of dependency confusion packages (A dependency confusion attempt against VMware VSphere SDK devs was just caught by us, along with 1000+ packages targeting Azure developers caught between March & April - our blog posts will explain it all.
We've thus far flagged well over 65,000 suspicious packages including malware, dependency confusion attacks, typosquats, PoC tests, etc.).
In 2022, we are met with self-sabotage and protestware incidents that are on the rise: colors/faker, node-ipc, event-source-polyfill, styled-components, es5-ext, ... These have further complicated matters, and pushed us to fine-tune our algorithms. We can now no longer trust the original developer of a library either, as they are free to change their mind on a whim (they always were).
As pioneers of a proactive solution behind dependency confusion attacks and a company that's been consistently leading OSS malware discoveries every week, I'm obviously biased but I'll say whatever solution you implement, make sure to have something in place to protect your dependencies, components, and supply chain against these novel attacks. Vulnerabilities like Log4Shell or Spring4Shell, as serious as they are, are just the tip of the iceberg when you look at the entire OSS threat landscape that's evolving.
Hi there,
Ax Sharma here from Sonatype - I've written extensively about our malware/hijacked package findings almost every week now on the company blog. The automated malware detection bots flag anything that looks suspicious on npm/PyPI and "quarantine" the packages until a manual analysis from researchers is pending.
Nexus Firewall automatically blocks malware and malicious typosquats, hijacked packages and dependency confusion attacks with algorithms now being expanded to cover self-sabotages (In fact, I first broke news on dependency confusion along with researcher Alex Birsan on the company blog and BleepingComputer). As such, before the attacks even picked up steam, Sonatype already had a solution for it and been blocking these for months - but coordinated disclosure agreement for PoC research delayed our public disclosure.
Nexus IQ/Lifecycle is more for SBOM/vulnerabilities, including those without a CVE - e.g. reported via GitHub Issues and other sources. The vulnerability scanning looks for the exact occurrence of vulnerable code rather than just flagging any and all artifacts for a given component, which makes it quite precise imo.
For SCA, there's Sonatype Lift that connects to your GitHub repo for free so you can test drive it before moving on to other offerings.
That is a sound argument, even if integrity of the package was to check out (if npm tracks this internally at all).
Better to adopt a PyPI-style approach of temporarily "quarantining" packages while investigating allegations of malware for big-scale projects. Instead npm pulled the plug outright stating: "This package contained malicious code and was removed from the registry..." (generic placeholder page), which is inaccurate and likely to cause panic. https://www.npmjs.com/package/stylus