When it comes to infosec, don’t be Twitter

He was a famous hacker. Now, he's detailing his main concern with Twitter - CNN VideoPeiter “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.

7 thoughts on “When it comes to infosec, don’t be Twitter

  1. Wow, this is a violation of every security best practice, it’s a laundry list of what NOT to do. And Mudge’s firing looks extremely suspicious

  2. Great write-up on some lesson to learn. There is another important lesson for CISOs which is to protect yourself and your infosec team if you have a falling out with the CEO and InfoSec is being setup to be blamed as negligent. It’s unfortunate this is what is happening… see Uber’s new CEO and Joe Sullivan.

  3. Pingback: A reader’s guide to Twitter’s supposed demise | Web Informant

  4. Pingback: Book review: The exploits of Space Rogue (Cris Thomas) | Web Informant

Leave a Reply to Doug Dooley Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.