I talk about passkeys: what they are, how they work, and how they can be used to protect your identity and your logins. This is with Shaun St. Hill’s Tech and Main podcast. And I also get to tell a story about erector sets too.
Peiter “Mudge” Zatko worked to improve Twitter’s security posture during 2021 directly for Jack Dorsey. Last month he sent a 200+-page complaint uncovering many of its internal security bad practices. The document was widely distributed around various DC agencies, including the FTC, the SEC, the DoJ. A redacted version was also sent to Congress. This smaller document was shared with the Washington Post and made public online. You can watch his interview with CNN’s Donie O’Sullivan here.
Mudge was fired in January 2022 for poor performance and ineffective leadership. Which seems suspect just from that wording, and what I know about his level of professionalism, knowledge and sincerity. (Mudge was one of the L0pht hackers who famously testified before Congress in 1998, a story that I covered for IBM’s blog here.) Yet, I am not sure why it took many months before he circulated his document and obtained legal protection. Whether you agree with Mudge or not, the complaints make an interesting outline of what not to do to provide the best possible internal security.
Excessive access rights. Mudge said too many of Twitter’s staffers (he claimed about half of total staff) had access to sensitive information. Twitter had more than 40 security incidents in 2020 and 60 in 2021, most of which were related to poor access controls. Its production environment was accessible to everyone and not properly logged. This isn’t anything new: Twitter was hacked by a teen back in 2020 through a simple social engineering trick. Inappropriate access control is a very common problem, and an entire class of privilege access management tools has grown up that can be used to audit permissions.
Poor board communication of security posture. Mudge alleges that his research wasn’t properly communicated to Twitter’s board of directors as early as February 2021 and was told to prepare other documents that were “false and misleading” to the board’s risk committee. The proportion of incidents attributed to access control failures was also misrepresented to the board.
Poor compliance regimens. Security issues were brought up to compliance officials during Mudge’s tenure. But only after he was fired did he hear from these officials, which is documented in the complaint. Compliance is a two-headed process: you need to first figure out what private data you collect, and then ensure that it is properly protected. It appears Twitter did neither of these things and did them over a period of many years, creating what Mudge called “long overdue security and privacy challenges.” Mudge documented that Twitter never was in compliance with a 2011 FTC consent decree to fix handling private data, document internal systems and develop an appropriate software development plan. He also stated that the progress of all of these elements were misrepresented to both the board and FTC in subsequent filings.
Sloppy offboarding. Do you terminate access rights when employees leave? Twitter didn’t: A software engineer demonstrated that 18 months after his departure, he was still able to access code repositories on GitHub. When this was made public, his access was only then removed.
Where are the bots? An entire section of Mudge’s report is devoted to “lying about bots to Elon Musk.” Note the timing of this: Mudge was fired months before Musk began his mission to acquire the company. Mudge claims Twitter provided false and misleading information to Musk, saying they couldn’t accurately report on the number of bots on their platform, and citing various SEC reporting requirements. Mudge’s claim was if this number was ever measured properly, it would harm Twitter’s image and stock valuation. Twitter executives also received bonuses not for cutting spam and bots but for growing user numbers.
Lack of updated systems. Half of the staff PCs had disabled software and security updates and patching on their systems, such as endpoint firewalls or enabling remote desktop software. This is also a common problem, and Twitter had no corporate view of the security posture across its computer population. Nor was this situation ever properly communicated to Twitter’s board, who were originally told that 92% of the PCs were secured.
Lack of any insider threat detection or response. Mudge discovered that more than 1,500 daily failed logins were never investigated. Many employees had copies of data from production systems. Both are wide open invitations for hackers to compromise their systems.
Lack of any backup regimen. No employee PCs were ever backed up. At one point, Twitter had implemented a backup system, but it was never tested and didn’t work properly.
Twitter has claimed they have made security improvements since Mudge left the company. Mudge points out this blog post from September 2020 (during his tenure at Twitter) co-written by CEO Parag Agrawal, as filled with false claims that his document goes through at length to illuminate. Clearly, from what I know Twitter has a long way to go to improve their security practice. Hopefully, some of the items mentioned above are under control in your own business.
Mudge testifies before the Senate Judiciary Cmte. today, watch the stream.
In the last couple of weeks I have seen business relationships sour over bad software security. The two examples I want to put forward for discussion are:
Both breaches had larger consequences. In Digital Ocean’s case, the lack of MailChimp’s response (which was two days) was one of the reasons for switching list serve providers. Signal had 1900 customer accounts that were at risk and is still using Twilio. Twilio’s breach response has also been criticized in this blog post, and the breach has spilled over elsewhere: Cloudfare announced that 76 of their employees had experienced a similar attack in the same time frame but didn’t fall for it.
What is happening here is a warning sign for every business. This isn’t just a software supply chain issue but a more subtle situation about how you use someone’s software tools in your daily operations. And if basic services are at risk, such as mailing lists and phone number verifications, what about things that are more complex that are part of your software stack?
Here are a few tips. If you use Signal, go to your phone to Signal Settings > Account > Registration Lock and make sure it is enabled. This will prevent these kinds of compromises in the future. Also update your phone to the latest Signal version too. Take a moment to explore other third party software providers and ensure that your APIs have been set up with the most secure authentication options possible. This includes cloud storage containers: the latest cloud-native security report from Sysdig found that 73% of cloud accounts contained exposed Amazon S3 buckets with no authentication whatsoever.
We recently learned about major security breaches at two tech companies, Twilio and Slack. The manner in which these two organizations responded is instructive, and since both of them published statements explaining what happened, it’s interesting to observe the differences in their communication, along with some lessons learned for your own breach planning and response. You can read more about the situations in my latest blog post for Avast.
I first met Dave Piscitello in the late 1990s when we served together on the Interop+Networld conference program committee, and collaborated on several consulting reports. He went on to create his own conference on internet security that ran from 1997-2000, then went on to work on security for ICANN until 2018. He serves on several international do-gooder infosec boards and is part of a consultancy called the Cybercrime Information Center that produces some very excellent reports on the state of malware, phishing, and domain name abuses. The most current report is on phishing, which shows that monthly attacks have doubled since May 2020. What makes his report powerful is that includes data from four commercial information sources, which collected more than a million unique attacks and publish their own blocklists. I wrote about his work and the state of phishing for my latest Avast blog here.
Interest in multi-factor authentication (MFA) has risen in the past few years, spurred by the increasing frequency and severity of data breaches and destructive attacks. When Covid-19 happened, ransomware actors proliferated. Recently, MFA has received a boost from various supporters, including Google, the US federal government, GitHub and Microsoft. When evaluating the various MFA products and technologies on the market today, it’s important to understand the tradeoffs in security, scalability and usability inherent in each option. Additionally, it can be helpful to understand your available choices in the context of how MFA has developed over time.
In this ebook I co-authored with Evan Krueger, the engineering manager of Token, we track the evolution of MFA, the work of the FIDO Alliance to bring the industry together and provide new authentication standards, and some suggestions on how to choose the right MFA technology that you carry with you, that understands your biometrics, and can be married to your identity without any operator intervention. Ransomware and data theft are only increasing in severity. It’s time for the defenders to up their game as well.
Last summer, I wrote about a major international investigation of the NSO Group and its Pegasus spyware. We described how it works and what you can do to protect your phone. NSO has gone through some difficult times as a result of that analysis. NSO was almost purchased by an American company that is closely linked to intelligence operations until the US Government put them, along with another Israeli spyware vendor Candiru, on a special block list that prevents both from obtaining government contracts. Candiru, you might recall, was discovered to be doing its own zero-day spying by Avast researchers.
In my post today for Avast’s blog, I review what transpired at a recent hearing held by the House Intelligence Committee. There were three witnesses who emphasized the threat of spyware to various democracies around the world, and provided lots of specifics about how Pegasus has operated.
The initial phases of a breach are often the most critical: The intruder is counting on your confusion, your lack of a plan or a clear chain of authority, and any early missteps. Given that it’s only a matter of time before a breach happens, what can you do after encountering an incident to minimize the damage?
For businesses of all sizes, incident response planning infrastructures have gotten very complex, with many interconnected relationships that might not be immediately obvious — until something goes wrong. In this blog for Avast, I outline how you can prepare for an incident in a well-thought-out and organized manner.
Magecart, the notorious credit card stealing cybercrime syndicate, is once again in the news. It is the gift that keeps on giving – it has recently taken root in three different online restaurant ordering websites: MenuDrive, Harbortouch, and InTouchPOS. The malware was found in more than 300 restaurants that used them and exposed more than 50,000 paid orders. The malware was present in some of these systems for many months before they were discovered. Indeed, some attacks began last November and are still active.
I’ve often made recommendations about patching your systems. Patching is a simple concept to explain: Keeping all your various digital components (hardware, software, and networking infrastructure) up to date with the most recent versions. However, it can be easier said than done – this is due to the fact that our day-to-day operations have become complex systems that interconnect and intersect in ways that are hard to predict. In this blog post for Avast, I review some of the benefits of timely patching, how to get a patching program established and operational, and some notable failures about patching over the years.