Nothing quite like starting the day by refreshing a password that was apparently compromised, and then trying to determine where/how the operators might have obtained the login credentials in the first place. Still, props to Google’s AI systems for detecting the aberrant login attempt and blocking it, as well as for password managers which make having unique login credentials for every service so easy to manage/replace.
Between 2002 and 2009, the [Industrial Control System Cyber Emergency Response Team] conducted more than 100 site assessments across multiple industries–oil and natural gas, chemical, and water–and found more than 38,000 vulnerabilities. These included critical systems that were accessible over the internet, default vendor passwords that operators had never bothered to change or hard-coded passwords that couldn’t be changed, outdated software patches, and a lack of standard protections such as firewalls and intrusion-detection systems.
But despite the best efforts of the test-bed and site-assessment researchers, they were battling decades of industry intertia–vendors took months and years to patch vulnerabilities that government researchers found in their systems, and owners of crucial infrastructure were only willing to make cosmetic changes to their systems and networks, resisting more extensive ones.
– Kim Zetter, Countdown to Zero-Day
Matt Green has a good writeup of the confusion associated with Apple’s decision to relocate Chinese users’ data to data centres in China. He notes:
Unfortunately, the problem with Apple’s disclosure of its China’s news is, well, really just a version of the same problem that’s existed with Apple’s entire approach to iCloud.
Where Apple provides overwhelming detail about their best security systems (file encryption, iOS, iMessage), they provide distressingly little technical detail about the weaker links like iCloud encryption. We know that Apple can access and even hand over iCloud backups to law enforcement. But what about Apple’s partners? What about keychain data? How is this information protected? Who knows.
This vague approach to security might make it easier for Apple to brush off the security impact of changes like the recent China news (“look, no backdoors!”) But it also confuses the picture, and calls into doubt any future technical security improvements that Apple might be planning to make in the future. For example, this article from 2016 claims that Apple is planning stronger overall encryption for iCloud. Are those plans scrapped? And if not, will those plans fly in the new Chinese version of iCloud? Will there be two technically different versions of iCloud? Who even knows?
And at the end of the day, if Apple can’t trust us enough to explain how their systems work, then maybe we shouldn’t trust them either.
Apple is regarded as providing incredibly secure devices to the public. But as more and more of the data on Apple devices is offloaded to Apple-controlled Cloud services it’s imperative that the company both explain how it is securing data and, moreover, the specific situations under which it can disclose data it is stewarding for its users.
Blew away over 10K emails that were collecting dust in one of my main accounts. My goal over the next few months is to remove the mass majority of old email that serves no purpose. Doing so will both free up some space (not that I really need it) while also cutting down on the possible deleterious effects of having the account in question getting hacked and contents selectively modified and/or leaked.
From Ben Farthi:
In my role as the head of Microsoft security, I personally spent many years explaining to antivirus vendors why we would no longer allow them to “patch” kernel instructions and data structures in memory, why this was a security risk, and why they needed to use approved APIs going forward, that we would no longer support their legacy apps with deep hooks in the Windows kernel — the same ones that hackers were using to attack consumer systems. Our “friends”, the antivirus vendors, turned around and sued us, claiming we were blocking their livelihood and abusing our monopoly power! With friends like that, who needs enemies? They just wanted their old solutions to keep working even if that meant reducing the security of our mutual customer — the very thing they were supposed to be improving.
Anti-virus programs remain a problem in terms of the attack surface they can open up. This surface, combined with the failure of many products to effectively identify and act on malware signatures, means that consumers tend to put far too much trust in products that often function poorly at best.
Robert Graham has helpfully explained what the Meltdown and Spectre vulnerabilities mean for most end-users. In short: patch now and things should be ok. But chipmakers and OS vendors are going to have to rethink some baseline ways of doing business.
Per Wordfence there are four reasons for supply-chain (i.e. plugin-based) attacks on WordPress installations:
The first reason is simply scale. According to w3techs, WordPress powers 29.2% of all websites – a massive user base to go after. In addition, at the time of this writing there were 53,566 plugins available for download in the official WordPress.org plugin repository. That is a lot to work with on both fronts.
Secondly, the WordPress.org plugin directory is an open, community-driven resource. According to the plugin guidelines page, “It is the sole responsibility of plugin developers to ensure all files within their plugins comply with the guidelines.” This means that while there is a small team tasked with managing the plugin repository and another small team focused on security, ultimately users rely on plugin developers to keep them safe.
Thirdly, most WordPress sites are managed pretty casually. Making a change to a website at a larger company might include code review, testing and a formal change control process. But that’s probably not happening consistently, if at all, on most smaller websites. In addition, many site owners don’t monitor their WordPress sites closely, which means malware can often remain in place for many months without being discovered.
Lastly, the WordPress plugin repository has a huge number of abandoned plugins. When we looked back in May, almost half of the available plugins hadn’t been updated in over two years. This represents a great opportunity for ne’er do wells looking to con unsuspecting plugin authors into selling something they created years ago and have moved on from.
The aforementioned points outline why acquiring and infecting WordPress plugins is a reasonable way of penetrating WordPress installs. However, I think that Wordfence is missing the most important reason that such attacks succeed: few actual users of WordPress are technically component to monitor what, exactly, their plugins are doing. Nor are the shared hosting services particularly good at identifying and alerting technically-illiterate users that their sites are compromised and what the site owners need to do to remediate the intrusion.
Trying to get individual users to more carefully monitor how their plugins work is a fool’s errand. What’s needed is for hosts to provide a community service and actively not just identify hijacked plugins (and sites) but, also, provide meaningful remediation processes. User education and alerts aren’t enough (or even moderately sufficient): companies must guide site owners through the process of cleaning their sites. Otherwise malware campaigns aimed at WordPress will persist and grow over time.