Avast blog: How Uber was hacked — again

Last week, an 18-year old hacker used social engineering techniques to compromise Uber’s network. He compromised an employee’s Slack login and then used it to send a message to Uber employees announcing that it had suffered a data breach. Uber confirmed the attack on Twitter within hours, issuing more details on this page.

CSO went into details about how the attack happened.

The company claims no user data was at risk, they have notified law enforcement, and all of their services have been restored to operational status. In this post for Avast, I explain what happened and suggest a few lessons to be learned from the experience on how to prevent a similar attack from happening to your business.

Using Data Theorem’s Cloud Secure to protect cloud native applications

We tested Data Theorem’s Cloud Native Application Protection Platform called Cloud Secure in September 2022. Cloud Secure provides two major advantages:

  • It includes extensive and free CSPM protection to any customer
  • It automates cloud hacking with its Hacker Toolkits. These automate full-stack attacks of popular data breaches. This option starts at $4000 for an annual subscription.

Cloud Secure is one of five products that make up a CNAPP solution that offers a full stack security approach to all  their cloud-based applications. With full stack security, customers can visualize and take action on all their first and third-party APIs, cloud resources, mobile, and web applications built on cloud-native services. Data Theorem has a central analysis, policy and reporting engine that works across its product line. They protect workloads on Amazon Web Services, Google Cloud Platform, Kubernetes clusters and Microsoft Azure clouds.

Cloud Secure is available Cloud Secure is available for a 30-day free trial, and can be purchased from the three major cloud marketplaces, with full pricing details available here.

CSOonline: CNAPP buyer’s guide

Cloud security continues to be a vexing situation, and the tool set continues to become more complex, riddled with acronyms. Enter the Cloud Native Application Protection Platform or CNAPP. IT managers are looking for a few basic elements from these products, including more accurate threat detection, support for all workloads across multiple cloud deployments, and ways to implement preventable controls.

cso cnapp vendors tableEven still, that is a lot of software to manage, integrate, and understand. However, almost none of the products that claim to be CNAPP have a full set of features that incorporate all four of these categories. In this post for CSOonline, I explain the landscape and show you how to navigate amongst the contenders.

Avast blog: The latest privacy legal environment is getting interesting

California’s privacy laws have now been in effect for more than two years, and we are beginning to see the consequences. Earlier this month, the California Attorney General’s office released the situations where various businesses were cited and in some cases fined for violations. It is an interesting report, notable for both its depth and breadth of cases.

The CalAG is casting a wide net and in my blog for Avast I discuss what happened there and how the  privacy legal situation is evolving elsewhere. I also offer some words of advice to keep your business from getting caught up in any potential legal action.

Avast blog: The rise of ransomware and what can be done about it

new report by John Sakellariadis for the Atlantic Council takes a deeper dive into the rise of ransomware over the past decade and is worth reading by managers looking to understand this marketplace. In my latest blog for Avast, I explore the reasons for ransomware’s rise over the past decade — such as more targeted attacks, inept crypto management, and failed federal policies — as well as measures necessary to start investing in a more secure future.

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.

Watch that API!

Things to Look Out for When Building Secure APIsIn 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.

Avast blog: A tale of two breaches: Comparing Twilio and Slack’s responses

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.

Avast blog: Dave Piscitello working to make the internet a more secure place

Dave Piscitello of Interisle Consulting Group: 5 Things You ...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.