Why We CVE
A look at what CVE is and why F5 is a member of the CVE program and discloses vulnerabilities. Background First, for those who may not already know, I should probably explain what those three letters, CVE, mean. Sure, they stand for “Common Vulnerabilities and Exposures”, but that does that mean? What is the purpose? Borrowed right from the CVE.org website: The mission of the CVE® Program is to identify, define, and catalog publicly disclosed cybersecurity vulnerabilities. There is one CVE Record for each vulnerability in the catalog. The vulnerabilities are discovered then assigned and published by organizations from around the world that have partnered with the CVE Program. Partners publish CVE Records to communicate consistent descriptions of vulnerabilities. Information technology and cybersecurity professionals use CVE Records to ensure they are discussing the same issue, and to coordinate their efforts to prioritize and address the vulnerabilities. To state it simply, the purpose of a CVE record is to provide a unique identifier for a specific issue. I’m sure many of those reading this have dealt with questions such as “Does that new vulnerability announced today affect us?” or “Do we need to worry about that TCP vulnerability?” To which the reaction is likely exasperation and a question along the lines of “Which one? Can you provide any more detail?” We certainly see a fair number of support tickets along these lines ourselves. It gets worse when trying to discuss something that isn’t brand new, but years old. Sure, you might be able to say “Heartbleed”, and many will know what you’re talking about. (And do you believe that was April 2014? That’s forever ago in infosec years.) But what about the thousands of vulnerabilities announced each year that don’t get cute names and make headlines? Remember that Samba vulnerability? You know, the one from around the same time? No, the other one, improper initialization or something? Fun, right? It is much easier to say CVE-2014-0178 and everyone knows exactly what is being discussed, or at least can immediately look it up. Heartbleed, BTW, was CVE-2014-0160. If you have the CVE ID you can look it up at CVE.org, NVD (National Vulnerability Database), and many other resources. All parties can immediately be on the same page with the same basic understanding of the fundamentals. That is, simply, the power of CVE. It saves immeasurable time and confusion. I’m not going to go into detail on how the CVE program works, that’s not the intent of this article – though perhaps I could do that in the future if there is interest. Leave a comment below. Like and subscribe. Hit the bell icon… Sorry, too much YouTube. All that’s important is to note that F5 is a CNA, or CVE Numbering Authority: An organization responsible for the regular assignment of CVE IDs to vulnerabilities, and for creating and publishing information about the Vulnerability in the associated CVE Record. Each CNA has a specific Scope of responsibility for vulnerability identification and publishing. Each CNA has a ‘Scope’ statement, which defines what the CNA is responsible for within the CVE program. This is F5’s statement: All F5 products and services, commercial and open source, which have not yet reached End of Technical Support (EoTS). All legacy acquisition products and brands including, but not limited to, NGINX, Shape Security, Volterra, and Threat Stack. F5 does not issue CVEs for products which are no longer supported. And F5’s disclosure policy is defined by K4602: Overview of the F5 security vulnerability response policy. F5, CVEs, and Disclosures While CVEs have been published sporadically for F5 products since at least 2002 (CVE-1999-1550 – yes, a 1999 ID but it was published in 2002 – that’s another topic), things really changed in 2016 after the creation of the F5 SIRT in late 2015. One of the first things the F5 SIRT did was to officially join the CVE program, making F5 a CNA, and to formalize F5’s approach to first-party security disclosures, including CVE assignment. This was all in place by late 2016 and the F5 SIRT began coordinating F5’s disclosures. I’ve been involved with that since very early on, and have been F5’s primary point of contact with the CVE program and related working groups (I participate in the AWG, QWG, and CNACWG) for a number of years now. Over time I became F5’s ‘vulnerability person’ and have been involved in pretty much every disclosure F5 has made for a number of years now. It’s my full-time role. The question has been asked, why? Why disclose at all? Why air ‘dirty laundry’? There is, I think, a natural reluctance to announce to the world when you make a mistake. You’d rather just quietly correct it and hope no one noticed, right? I’m sure we’ve all done that at some point in our lives. No harm, no foul. Except that doesn’t work with security. I’ve made the argument about ‘doing the right thing’ for our customers in various ways over the years, but eventually it distilled down to what has become something of a personal catchphrase: Our customers can’t make informed decisions about their networks if we don’t inform them. Networks have dozens, hundreds, thousands of devices from many different vendors. It is easy to say “Well, if everyone keeps up with the latest versions, they’ll always have the latest fixes.” But that’s trite, dismissive, and wholly unrealistic – in my not-so-humble opinion. Resources are finite and prioritizations must be made. Do I need to install this new update, or can I wait for the next one? If I need to install it, does it have to happen today, or can it wait for the next scheduled maintenance? We cannot, and should not, be making decisions for our customers and their networks. Customers and networks are unique, and all have different needs, attack surfaces, risk tolerance, regulatory requirements, etc. And so F5’s role is to provide the information necessary for them to conduct their own analysis and make their own decisions about the actions they need to take, or not. We must support our customers, and that means admitting when we make mistakes and have security issues that impact them. This is something I believe in strongly, even passionately, and it is what guides us. Our guiding philosophy since day one, as the F5 SIRT, has been to ‘do the right thing for our customers’, even if that may not show F5 in the best light or may sometimes make us unpopular with others. We’re there to advocate for improved security in our products, and for our customers, above all else. We never want to downplay anything, and our approach has always been to err on the side of caution. If an issue could theoretically be exploited, then it is considered a vulnerability. We don’t want to cause undue alarm, or Fear, Uncertainty, and Doubt (FUD), for anyone, but in security a false negative is worse than a false positive. It is better to take an action to address an issue that may not truly be a problem than to ignore an issue that is. All vendors have vulnerabilities, that’s inevitable with any complex product and codebase. Some vendors seem to never disclose any vulnerabilities, and I’m highly skeptical when I see that. I don’t care for the secretive approach, personally. Some vendors may disclose issues but choose not to participate in the CVE program. I think that’s unfortunate. While I’m all for disclosure, I hope those vendors come to see the value in the CVE program not only for their customers, but for themselves. It does bring with it some structure and rigor that may not otherwise be present in the processes. Not to mention all of the tooling designed to work with CVEs. I’ve been heartened to see the rapid growth in the CVE program the past few years, and especially the past year. There has been a steady influx of new CNAs to the program. The original structure of the program was fairly ‘vendor-centric’, but it has been updated to welcome open-source projects and there has been increasing participation from the FOSS community as well. The Future In 2022 F5 introduced a new way of handling disclosures, our Quarterly Security Notification (QSN) process, after an initial trial in late 2021. While not universal, the response has been overwhelmingly positive – you may not be able to please all the people, all the time, but it seems you can please a lot of them. The QSN was primarily designed to make disclosures more predictable and less disruptive to our customers. Consolidating disclosures and decoupling them from individual software releases has allowed us to radically change our processes, introducing additional levels of review and rigor. At the same time, independent of the QSN process, the F5 SIRT had also begun work on standardized language templates for our Security Advisories. As you might expect, there are teams of people who work on issues – engineers who work on the technical evaluation, content creators, technical writers, etc. With different people working on different issues, it was only natural that they’d find different ways to say the same thing. We might disclose similar DoS issues at the same time, only to have the language in each Security Advisory (SA) be different. This could create confusion, especially as sometimes people can read a little too much into things. “These are different, there must be some significance in that.” No, they’re different because different people wrote them is all. Still, confusion or uncertainty is not what you want with security documentation. We worked to create standardized templates so that similar issues will have similar language, no matter who works on the issue. I believe that these efforts have resulted in a higher quality of Security Advisory, and the feedback we’ve received seems to support that. I hope you agree. These efforts are ongoing. The templates are not carved in stone but are living documents. We listen to feedback and update the templates as needed. When we encounter an issue that doesn’t fit an existing template a new template is created. Over time we’ve introduced new features to the advisories, such as the Common Vulnerability Scoring System (CVSS) and, more recently, Common Weakness Enumeration (CWE). We continue to evaluate feedback and requests, and industry trends, for incorporation into future disclosures. We’re currently working on internal tooling to automate some of our processes, which should improve consistency and repeatability – while allowing us to expand the work we do. Frankly, I only scale so far, and the cloning vats just didn’t work out. Having more tooling will allow us to do more with our resources. Part of the plan is that the tooling will allow us to provide disclosures in multiple formats – but I don’t want to say anything more about that just yet as much work remains to be done. So why do we CVE? For you – our customers, security professionals, and the industry in general. We assign CVEs and disclose issues not only for the benefit of our customers, but to lead by example. The more vendors who embrace openness and disclose CVEs, the more the practice is normalized, and the better the security community is for it. There isn’t really any joy in being the bearer of bad news, other than the hope that it creates a better future. Postscript If you’re still reading this, thank you for sticking with me. Vulnerability management and disclosure is certainly not the sexy side of information security, but it is a critical component. If there is interest, I’d be happy to explore different aspects further, so let us know. Perhaps I can peel back the curtain a bit more in another article and provide a look at the vulnerability management processes we use internally. How the sausage, or security advisory, is made, as it were. Especially if it might be useful for others looking to build their own practice. But I like my job so I’ll have to get permission before I start disclosing internal information. We welcome all feedback, positive or negative, as it helps us do a better job for you. Thank you.F5 BIG-IP Advanced WAF – DOS profile configuration options.
F5 BIG IP Advanced WAF is the perfect tool for detection and prevention of application Distributed Denial-of-Service (DDoS) attacks against a web application. This article will review the possible configurations of the dos profile also known as Adv WAF anti DDoS feature to stop those attacks.Government, Google, and GitHub - March 11th - 17th, 2023 - F5 SIRT - This Week in Security
Editor's introduction Let's spin the wheel of editors and see where it lands this week... MegaZone. Hi folks, it's me again. Reaching into the grab bag of security news from last week I pulled out a handful of items that particularly caught my interest. The longest-term impact will likely come from the National Cybersecurity Strategy. This administration seems to be getting serious about cybersecurity with a number of executive directives to date, and this strategy continues that trend while foreshadowing future mandates. We're also seeing regulatory movement from the SEC, and some enforcement action from the FBI. On the industry side, Google Project Zero released a bundle of vulnerabilities for Samsung Exynos Modems which have serious implications for a number of devices, especially popular Android phones from Samsung and Google. And GitHub is improving account security with 2FA, but the larger issue of secrets leaking via repositories continues to worsen. I encourage you to check out the earlier editions of TWIS, and the broader content shared by the F5 SIRT. I think there is some good content there, but I might be a wee bit biased. 2023 National Cybersecurity Strategy The Biden Administration has released their 2023 National Cybersecurity Strategy, and thirty-nine page document that will certainly reverberate throughout the industry. Clearly the push is to make vendors, not users, primarily responsible for cybersecurity - including legal and financial responsibility. The idea is nothing new, I remember Bruce Schneier saying something similarly a couple of decades ago, but it seems we're finally seeing some force behind it. If vendors bear responsibility for the security of their products and services they have a business incentive to improve said security. Expect more regulations to this effect - regulation is a recurring theme in the strategy. Even before regulations there will be immediate impact will be on vendors selling to government customers, but this will also 'trickle down'. Those in the supply chain to government vendors are going to face pressure to meet the same standards. Other customers will follow the US government's lead - other nations, of course, but we're already seeing large commercial customers asking for the same commitments as the government. A good indicator is the Software Bill Of Materials, or SBOMs. Interest in SBOMs has picked up across large customers since the US government laid out requirements for vendors to start producing them. The doors have been opened, expect more to pass through them. It is past time for the industry to get our house in order. This is just the beginning. https://www.whitehouse.gov/wp-content/uploads/2023/03/National-Cybersecurity-Strategy-2023.pdf https://www.scmagazine.com/perspective/leadership/four-ways-to-give-the-national-cybersecurity-strategy-some-teeth Google Project Zero Exposes Samsung Exynos Modems RCEs I'm pretty deeply invested in the Google ecosystem (though I'm still pissed about Stadia shutting down, even if I did get a refund), and that goes for my phone too. I've been an Android user since the Motorola Droid came out (replacing my Treo680), and more specifically I've gravitated to Google's 'pure Android' devices, like the Nexus products back in the day (Samsung Galaxy Nexus), and more recently the Pixel family. I've had a Pixel 2 XL, Pixel 4 XL, and currently a Pixel 6 Pro (and a Pixel Watch). So I wasn't too thrilled when Google Project Zero broke the news last week of multiple baseband RCEs in the Samsung Exynos modems used in Pixel, and Samsung, devices, amongst others. As a darkly joked about on social media, I bet intelligence agencies around the world were cursing GPZ. This is just the kind of thing your friendly neighborhood intel agent would use to remotely suborn a target's phone. No user interaction required, no indications of compromise to the user, no need to touch the device. All you need is their phone number. The issues are bad enough that GPZ is making an exception to their usually-firm 90-day disclosure policy for the four more severe issues, giving vendors more time to patch. The good news for Pixel users is that Google already released patches for the four most severe issues in the March security update. Which is nice, since the recommended mitigation of disabling both WiFi calling and Voice-over-LTE (VoLTE) is not that practical for many users of modern networks. Many use WiFi calling for better quality connections in areas with weak cellular service, not to mention reduced cost, and VoLTE is required for some networks and plans as they move to only 4G LTE & 5G. Some may not even allow you to disable these in settings. https://googleprojectzero.blogspot.com/2023/03/multiple-internet-to-baseband-remote-rce.html https://semiconductor.samsung.com/support/quality-support/product-security-updates/ https://source.android.com/docs/security/bulletin/pixel/2023-03-01 GitHub Mandatory 2FA - But Issues Remain On March 13th GitHub began the rollout mandatory two-factor authentication (2FA) for all developers, with the objective of universal use by the end of 2023. This increases the security of GitHub by reducing incidents of accounts, and thereby the projects linked to those accounts, being hijacked by malicious actors. As GitHub is a major component of today's software supply chain, this is a growing threat. (If you're a GitHub user, beat the rush and configure 2FA today - if you haven't already.) However, while this change is laudable, it isn't the only credential issue at GitHub. GitHub has a serious, continuing issue with credentials, and other secrets, getting checked into repositories for all to see. The State of Secrets Sprawl 2023, by GitGuardian, shows a 67% increase over 2022 in secrets checked into GitHub, to over 10 million instances out of over one billion new commits, with 3 million unique secrets. Fully one in ten developers checked in at least one secret - 1.35 million out of 13.3 million. And 5.5 commits out of every 1,000 exposed at least one secret. 2FA isn't going to help with that - only better developer practices will. The report is a quick read - and worth sharing with your developers. These leaked secrets were used in major attacks in 2022, as well as compromising apps, private data, customer information, etc. Hardcoding secrets, credentials or otherwise, into software is simply a bad practice. Stop doing it. Every as a 'temporary' solution for testing - we all know how permanent 'temporary' solutions often turn out to be. And while won't help with this, as a general rule whenever you're offered 2FA/MFA - use it. Yes, even SMS 2FA is better than not using it at all. If you have the option of using an authenticator app (I like Authy), a security key, or a passkey, even better. https://github.blog/2023-03-09-raising-the-bar-for-software-security-github-2fa-begins-march-13/ https://docs.github.com/en/authentication/securing-your-account-with-two-factor-authentication-2fa https://www.gitguardian.com/files/the-state-of-secrets-sprawl-report-2023 SEC Eyes Cybersecurity Turning once again to the subject of government and cybersecurity, the US Securities and Exchange Commission (SEC) is also taking cybersecurity more seriously these days. They've proposed new regulations which would require customer notification of data breaches within 30 days, with immediate government notification, while also expanding the type of information protected by data privacy regulations. The SEC is serious about their cybersecurity regulations too, as Blackbaud discovered to the tune of $3 million. Blackbaud had suffered a breach with data exfiltration and a ransomware attack, but underreported the severity of the incident to customers. While they claimed the attack did not leak banking information or Social Security numbers, but 'only' names, contact info, and some health data, the truth was that not only were bank details and SSNs compromised, but also usernames and password. The SEC criticised Blackbaud's disclosure controls and procedures, and slapped them with the $3 million fine. I expect to see more government agencies issuing their own cybersecurity regulations for their areas of responsibility. https://www.sec.gov/news/press-release/2023-51 https://www.sec.gov/news/press-release/2023-52 https://www.sec.gov/news/press-release/2023-53 https://www.sec.gov/news/press-release/2023-54 https://www.sec.gov/news/press-release/2023-48 FBI Pounces On Pompompurin And one last government story - the FBI arrested the alleged admin of BreachForums, Conor Brian Fitzpatrick aka Pompompurin. BreachForums is, or was considering it is down now, a popular cybercrime forum known for the publication of numerous hacked databases. In 2021 Fitzpatrick had taken credit for a breach of FBI systems that was used to send thousands of false emails relating to investigations. That's probably a good way to get on the FBI's bad side, if I had to guess. And then in December, 2022 members of BreachForums reportedly infiltrated the FBI's InfraGuard program and sold information on 80k program members on the forums. So I have to imagine that the FBI has been eager to shut down BreachForums. This is a win, but just as BreachForums emerged after the FBI shut down RaidForums last year, I'm sure another site will take its place. We don't have any shortage of criminals, or badly configured sites to breach it seems. https://www.theverge.com/2023/3/18/23646476/feds-arrest-alleged-hacking-forum-owner-breachforums-pompompurin https://krebsonsecurity.com/2023/03/feds-charge-ny-man-as-breachforums-boss-pompompurin/Trust, Supply Chain, CVEs, Patching, and Schneier - Nov 5th - 11th - F5 SIRT - This Week in Security
Editor's introduction Hello all, MegaZone is back in the editor's chair this week. This time around I present a collection of topics which have one thing in common - they caught my attention and interest enough to make a note to myself to remember them when it came time to compile This Week in Security. And, remarkably, I have - and here we are. The first entry, Delegation of Trust, originally caught my eye via Cory's Tweets, and certainly caught my interest enough to spend some time looking for more information. It does raise some suspicions for me as the behaviors and issues cited, while they could have innocent explanations, certainly seem questionable for a supposedly reputable vendor. Supply Chain Security has been a major topic in the Infosec world for several years now. It seemed to really come to the fore with the 2018 Bloomberg article which claimed Chinese vendors had embedded tiny spy chips into major products. The story was widely denied, debunked, and discredited by all of the companies named, but it certainly focused attention on the supply chain which has remained. Now the NSA, CISA, and ODNI are publishing supply chain security guidelines. When I'm not writing This Week in Security, I live and breath vulnerabilities at F5. Most of the day-to-day work I do is related to vulnerability management and disclosure - from tracking, to working with product teams to secure fixes, to publication and disclosure. And some of that work includes being F5's primary contact point with the CVE.org, as a CNA, and participating in a few working groups. Recently CVE Services 2.1 & the CVE JSON 5.0 Schema Launched, and I thought some of you might be interested in the mechanisms behind the scenes. Finally, a couple of quick items. The MS Patch Tuesday this week contained several zero-day patches and it is highly recommended that you patch systems ASAP - hopefully that's already done by the time this is published. And Bruce Schneier has announced a new book on the way, A Hacker's Mind, available for pre-order now. Until next time! Delegation of Trust Cory Doctorow posted an interesting examination of the delegation of trust. Everyday we trust in systems we use - but what is that trust built on? You may trust your browsers and PKI for TLS. But that's just the first layer. There are many, many layers of trust involved - all the way down to the compiler used. Or the compiler that compiled that compiler. The hardware it is all running on - and all of the individual vendors behind the components in that HW. Beyond that are trust in systems - commercial and government. And the people who comprise those systems. All of this serves as a background to the meat of the article - which is a look at Trustcor as a Certificate Authority, and why they're arguably problematic and may be undermining the web of trust millions of daily transactions are built upon. Trustcor is one of the root CAs trusted by default in Chrome, Firefox, and Safari - meaning they can provide certificates which compromise all TLS traffic in those browsers. Which isn't to say they are, just that they can, and some things about the company are more than a bit off. I found it an engaging and interesting read, and I encourage you to spend a few minutes reading it for yourself. Cory's article got me to looking, and The Washington Post also covered the Trustcor story. And researcher Prof. Joel Reardon goes further down the rabbit hole of questionable behavior by Trustcor and related firms. https://pluralistic.net/2022/11/09/infosec-blackpill/#on-trusting-trust https://twitter.com/doctorow/status/1590301458926161920 https://www.washingtonpost.com/technology/2022/11/08/trustcor-internet-addresses-government-connections/ https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/oxX69KFvsm4 Supply Chain Security The National Security Agency (NSA), the Cybersecurity and Infrastructure Security Agency (CISA), and Office of the Director of National Intelligence (ODNI) released a new report on supply chain security for suppliers - the aptly named Securing the Software Supply Chain: Recommended Practices Guide for Suppliers. This follows an earlier supply chain security report for developers - yes: Securing the Software Supply Chain: Recommended Practices Guide for Developers. Still to be published are recommended practices for customers, though I suspect we can predict that that will be titled when it is released. https://www.nsa.gov/Press-Room/News-Highlights/Article/Article/3204427/esf-partners-nsa-and-cisa-release-software-supply-chain-guidance-for-suppliers/ https://media.defense.gov/2022/Oct/31/2003105368/-1/-1/0/SECURING_THE_SOFTWARE_SUPPLY_CHAIN_SUPPLIERS.PDF https://www.cisa.gov/uscert/sites/default/files/publications/ESF_SECURING_THE_SOFTWARE_SUPPLY_CHAIN_DEVELOPERS.PDF CVE Services 2.1 & the CVE JSON 5.0 Schema Launched My primary role in the F5 SIRT is as "The Vulnerability Guy". I've been involved in the publication of nearly every F5 (and NGINX, etc.) CVE for several years now, and my role also includes acting as our primary point of contact with the CVE program, as F5 is a CNA (CVE Numbering Authority). In this role I have also been a participant in the CNA Coordination Working Group (CNACWG), the Automation Working Group (AWG), and the Quality Working Group (QWG). And the major projects of the latter two have recently launched! Those being CVE Services 2.1, from the CWG, and the CVE JSON 5.0 Schema, from the QWG. The two go hand-in-hand. As part of the launch activities, on November 2nd a half-day CVE Services Workshop was held, and now the materials and recordings of the sessions are available to all. There is also a site dedicated to the transition activities. While the primary audience for all of this is the CNA community, if you're interested in, or curious about, the inner-workings of the CVE program it is worth checking out. Especially if you're thinking of becoming a CNA yourself, or interact in other ways with the CVE program - for example as a security researcher or just as a consumer of CVE data. https://cveproject.github.io/CVE-Services-Workshop-Slides-02November2022-FINAL.pdf https://www.youtube.com/playlist?list=PLWfD9RQVdJ6etGbopVxE5Nb-8TzjY5cl9 https://cveproject.github.io/automation-transition MS Patch Tuesday This week's Microsoft Patch Tuesday was bountiful, with a large number of CVEs addressed, including eleven Critical severity issues. A few of those were zero-day vulnerabilities; the most severe of these, CVE-2022-41128, is a CVSS 8.8 resulting in Remote Code Execution. Most versions of Windows and Windows Server are affected, so patch early, patch often. https://www.forbes.com/sites/daveywinder/2022/11/08/windows-security-users-urged-to-update-as-4-new-zero-day-attacks-confirmed/ https://www.scmagazine.com/analysis/vulnerability-management/microsoft-patch-tuesday-fixes-six-zero-day-vulnerabilities New Bruce Schneier Book Bruce Schneier announced that he has a new book arriving in February, A Hacker's Mind. From the blurb: In A Hacker’s Mind , Bruce Schneier takes hacking out of the world of computing and uses it to analyze the systems that underpin our society: from tax laws to financial markets to democracy. He reveals an array of powerful actors whose hacks bend our economic, political, and legal systems to their advantage, at the expense of everyone else. https://www.schneier.com/blog/archives/2022/11/new-book-a-hackers-mind.html https://www.schneier.com/books/a-hackers-mind/CISA Needs You, Healthcare and Education Under Attack, and more - This Week in Security - Sept 5-11
This Week in Security September 5th to September 11th CISA Needs You, Healthcare and Education Under Attack, and The Usual Suspects Still Suspect MegaZone is back with you once again. Just back from PTO (Anaheim, what's up with the intense heat and tropical humidity? Jealous of Orlando?) and catching up on the news. Just have time to cherry pick a few things that caught my attention, before diving back into preparation for our next Quarterly Security Notification - coming October 19th. (You have that on the calendar, yes?) So, let's just jump right into it. CISA's New Incident Reporting Rules The US Cybersecurity and Infrastructure Security Agency (CISA) has issued an Request For Information (RFI) opening a sixty-day comment period on their proposed cyber incident reporting requirements. These comments will help shape the rules CISA is required to publish under the 2023 Cyber Incident Reporting for Critical Infrastructure Act (CIRCIA). It is a first step in developing the rules, which we'll eventually see in a Notice of Proposed Rulemaking (NPRM). These rules will potentially have a major impact on the information security industry, and this is the time for the industry to have their say to help shape those rules. https://www.cisa.gov/news/2022/09/09/cisa-welcomes-input-new-cyber-incident-reporting-requirements https://www.federalregister.gov/documents/2022/09/12/2022-19551/request-for-information-on-the-cyber-incident-reporting-for-critical-infrastructure-act-of-2022 https://www.scmagazine.com/analysis/incident-response/cisa-puts-out-the-call-for-public-feedback-on-new-incident-reporting-rules Healthcare under attack This caught my eye just by synchronicity. (And now I have a Police earworm.) Security news is always drinking from the firehose, and stories come and go so quickly, but as I was catching up on the week all at once I started noticing one story after another connected in some way with healthcare. Not too long ago a lot of adversaries deliberately steered clear of medical devices, hospitals, etc. to avoid too much negative perception. I recall at least once when a hospital was hit with ransomware, and when the responsible parties realized it was a hospital they just gave them the key to restore things. Ah, simpler times, long gone. These days everything goes, and if that ends up killing grandpa, well, that's just collateral damage. A real grabbag of issues came up over the past week. There's vulnerabilities in an ICU monitoring device and medical infusion pumps. Surely those are at all important. Of course, one of the vulnerabilities involves telnet, of all things. Why not rlogin? This is a common problem with medical devices, they often run ancient software and still support protocols the rest of the world has long since abandoned as hopelessly insecure. On the one hand we have medical certification which makes it hard to update things, and on the other we have devices increasingly connected to the network. That's not a good combination. Then there's report on the severity of the impact of ransomware on healthcare - one thing that caught my eye from that one: Overall, 89% of the surveyed organizations experienced an average of 43 attacks in the past 12 months, almost one attack per week. More than 20% suffering the four most common types of attacks — cloud compromise, ransomware, supply chain, and business email compromise — experienced increased patient mortality rates. So, yeah, these issues are literally killing people, lovely. Reinforced by another article on Oakbend Medical Center in Texas recovering from a ransomware attack. And this is rounded out by articles on a HIPAA data breach affected a quarter of a million people and, what feels almost in vain, an article on effectively using zero trust in healthcare. After reading the other articles that feels a bit like closing the barn door after the horses have bolted, but we're all fighting a never-ending battle to improve security. And there will always be a next time. https://www.scmagazine.com/analysis/device-security/cisa-warns-of-possible-ddos-risk-in-contec-patient-monitor-medical-devices https://thehackernews.com/2022/09/new-vulnerabilities-reported-in-baxters.html https://www.scmagazine.com/news/ransomware/the-cyberattack-with-the-most-negative-impact-to-patient-care-ransomware https://www.scmagazine.com/analysis/ransomware/texas-hospital-facing-communication-issues-system-rebuild-amid-ransomware-attack https://www.scmagazine.com/analysis/ransomware/law-firm-informs-255k-of-hipaa-data-incident-10-months-after-hack https://www.scmagazine.com/feature/zero-trust/effective-access-controls-key-to-employing-zero-trust-in-healthcare Education under attack And another bit of synchronicity. (You're welcome.) The other trend that caught my attention was the number of education institutions appeared in my feed. Education is under attack! No, not the book banning. No, not the anti-science curricula. No, not the sexist dress codes... Let's start over... ahem It is back-to-school time, and I guess that goes for attackers too. Won't someone think of the children! Sorry, don't know where that came from. Anyway, just more evidence that anything goes. We have the standard mix of issues these days, largely ransomware and cloud vulnerabilities. In this case it seems the LA School District got popped by Vice Society, one of many districts they've decided to target. Given the issues with school budgets I wouldn't think they could expect large payouts for the ransomware. But they're also stealing personal information on staff, faculty, and students, so perhaps they're also selling that info. https://www.scmagazine.com/news/cloud-security/almost-half-of-educational-institutions-had-a-cloud-based-cyberattack https://www.bleepingcomputer.com/news/security/second-largest-us-school-district-lausd-hit-by-ransomware/ https://www.scmagazine.com/analysis/ransomware/los-angeles-school-district-to-remain-open-despite-ransomware-attack https://www.bleepingcomputer.com/news/security/the-week-in-ransomware-september-9th-2022-schools-under-fire/ https://www.bleepingcomputer.com/news/security/fbi-warns-of-vice-society-ransomware-attacks-on-school-districts/ Spanning the Globe Finally, I tend to be somewhat US-focused, since that's where I live and where F5 is based, but infosec is definitely global. So I took note this week of the number of articles covering events around the globe. This week, unsurprisingly, there was a lot of attention on a few of the usual suspects - mostly Iran and North Korea, with an honorable mention for China. I can't say there is really anything new for those who watch world events in infosec, they're just up to their usual tricks. Only the targets change. I know it is serious, but it is hard not to get too worked up after years of the same kind of thing. Portugal makes an appearance as well, but as a victim. NATO documents stolen from Portugal have appeared for sale on the dark web. https://thehackernews.com/2022/09/iranian-apt42-launched-over-30.html https://www.bleepingcomputer.com/news/security/albania-blames-iran-for-july-cyberattack-severs-diplomatic-ties/ https://thehackernews.com/2022/09/us-imposes-new-sanctions-on-iran-over.html https://www.bleepingcomputer.com/news/security/us-sanctions-iran-s-ministry-of-intelligence-over-albania-cyberattack/ https://thehackernews.com/2022/09/microsoft-warns-of-ransomware-attacks.html https://www.bleepingcomputer.com/news/microsoft/microsoft-iranian-hackers-encrypt-windows-systems-using-bitlocker/ https://www.bleepingcomputer.com/news/security/new-iranian-hacking-group-apt42-deploys-custom-android-spyware/ https://thehackernews.com/2022/09/north-korean-lazarus-hackers-targeting.html https://thehackernews.com/2022/09/north-korean-hackers-spotted-using-new.html https://thehackernews.com/2022/09/chinese-hackers-target-government.html https://www.bleepingcomputer.com/news/security/classified-nato-documents-stolen-from-portugal-now-sold-on-darkweb/ That's all for this week. There was plenty of other news, of course, these are just the bits that caught my attention and seemed worth sharing. See you again in a few weeks when my turn comes around in the rotation again. Later!F5 NGINX HTTP Request Header Rules: What’s Permitted and What’s Not
When managing web servers like F5 NGINX, it's crucial to understand the rules that govern HTTP headers—particularly which characters are allowed or disallowed in both header names and values. HTTP headers play a vital role in the communication between a client and server, carrying essential metadata such as content type, length, and caching policies. NGINX strictly enforces these rules to ensure compliance with HTTP/1.1, HTTP/2, and HTTP/3 protocols. Misconfigured headers or the use of improper characters can lead to a range of issues, including security vulnerabilities, degraded performance, or even rejected requests. One common security threat, HTTP Request Smuggling, exploits desynchronization between devices involved in handling the request, such as frontends, caching servers, load balancers, and web servers. These attacks rely on inconsistencies in how each device parses the request, enabling malicious actors to inject hidden or split requests. This article outlines the allowed and disallowed characters in HTTP request headers as enforced by NGINX, which I compiled through code review, test case review and manual testing for HTTP Smuggling on NGINX version "nginx/1.25.5 (nginx-plus-r32-p1)". If I missed something please let me know by contacting the F5 SIRT. Allowed Characters Header Names Lowercase letters: (a-z) Uppercase letters: (A-Z) Allowed in HTTP/1.1 Disallowed in HTTP/2 and HTTP/3, which require lowercase. Digits: (0-9) Hyphen: (-) Underscore: (_) Allowed in all versions only if underscores_in_headers is enabled Colon: (:) Allowed only as a prefix in HTTP/2 and HTTP/3 pseudo headers. Header Values Printable ASCII characters: Characters from ! to ~, including digits, letters, punctuation, and symbols, are allowed. Space: (0x20) Allowed within the value. Horizontal Tab (HT): (0x09) Generally allowed within values but with exceptions in headers such as Content-Length and Host (details below). Disallowed Characters Header Names Control Characters: ASCII control characters (<= 0x20), including space and horizontal tab, are disallowed in header names. DEL (0x7f): The delete character is not allowed. Colon: (:) Disallowed in header names except for HTTP/2 and HTTP/3 pseudo headers. Uppercase Letters: (A-Z) Disallowed in HTTP/2 and HTTP/3 header names (must be lowercase). Special characters: Characters such as ()<>@,;:\"/[]?={} are implicitly disallowed as they don’t belong to any allowed category for header names. Header Values Null Character: (\0) Disallowed in header values. Line Feed (LF): (0x0A) Not allowed within the value and used only to terminate headers. Carriage Return (CR): (0x0D) Not allowed within the value, used for header termination. Control Characters (<= 0x20) with special conditions for Horizontal Tab (HT): Horizontal Tab (HT, 0x09): Disallowed in the Host header value in HTTP/1. Disallowed in the pseudo-header values in HTTP/2 and HTTP/3. Disallowed in the Content-Length header value in HTTP/1. Summary This list of allowed and disallowed characters provides an overview of how NGINX handles HTTP headers across different protocol versions. While HTTP/1.1 is somewhat lenient with uppercase letters and certain characters, HTTP/2 and HTTP/3 enforce stricter validation rules, particularly for header names. Understanding these restrictions ensures your server configuration remains compliant with protocol specifications and avoids potential issues with malformed headers.F5 SIRT - This Week in Security - June 20th to 26th, 2022 - USB(ooze), 24 Billion Credentials, I Spy
This Week in Security June 20-26, 2022 "USB(ooze), 24 Billion Credentials Can't Be Wrong, I Spy With My Little Eye" The theme this week is information and it's (mis)management. Drunk (USB) Driving To err is human, but adding alcohol definitely helps the process along. Of course, the prerequisite conditions for this colossal mistake would not have existed had proper information security procedures been followed. The information should not have been copied onto the USB drive in the first place. That rule having been broken, once the work was completed the information should have been deleted. Failing to do even that, not getting pass-out-in-the-gutter drunk with the unsecured drive in his bag might have been a better life, and career, choice. The drive is reportedly encrypted, which might offer some reassurance to the 465-thousand people whose personal information was on the missing drive. Though, given the worker's chain of excellent decisions I'm not sure I'd put a lot of faith in his correctly encrypting the drive. Drunken gentleman gets USB flash drive stolen — too bad it had personal info on every city resident | Boing Boing Japan: Man loses USB flash drive with data on entire Amagasaki city's residents after night out - CNN 24 BILLION Username/Password Combinations <Insert Your Own Dr. Evil 'Billion' Joke Here> For those of us in infosec the popularity of credential stuffing attacks is no surprise. They've been increasingly common over the past few years, aided by multiple massive credential leaks. But the number of username/password credentials available on the dark web is truly staggering now - 24 billion combinations. 6.7 billion unique - a 1.7 billion increase from 2020. For the average consumer, who will use one email address as their username pretty much everywhere (as is the de facto standard these days), this highlights the risk of password reuse. Leaks are so prevalent, and credential stuffing so common, that the risks are high for users who reuse their credentials. One leak and accounts on multiple sites may get popped. The best way to protect ourselves from this is by using unique passphrases (not just passwords) for each site, likely aided by password managers since our brains aren't great at remembering all of those, and using multi-factor authentication (MFA) (aka two-factor authentication (2FA)) everywhere it is offered. Using apps like Authy, Duo, Google Authenticator, etc., is probably the best choice for most users. Physical tokens are great, but the tradeoff in usability and convenience is probably not justified for most users. Even SMS-based authentication is better than nothing. Yes, SIM-jacking and other attacks exist, but the risk to any random user is fairly low. It isn't perfect, but it raises the level of effort required. Of course, unique passphrases would be a huge improvement given 1 out of 200 of the passwords in the collection are '123456'. And 49 of the 50 most common passwords can be cracked in under a second with standard tools. The users are not alright. 24+ Billion Credentials Circulating on the Dark Web in 2022 — So Far 24 billion username, password combinations can be found on cybercriminal forums | SC Media Ransomware Goes Big Nearly three million patient records, and counting, have been potentially compromised by a breach at Eye Care Leaders, a provider of electronic health records and patient management software solutions for eye care practices. The breach took place back in early December, but the scope - and tally of affected records - just keeps growing. Eye care providers large and small are affected - in the running list being maintained by HIPAA Journal the smallest provider had 1,337 patients at risk while the largest had 1,290,104. While there is not yet evidence that patient records were successfully exfiltrated or otherwise accessed, the systems with the information were compromised and patient record access or exfiltration cannot be ruled out. Eye Care Leaders claims they provide software solutions to over 9,000 ophthalmologists and optometrists, so the list of affected practices, and therefore the number of patient records at risk, seems likely to continue to grow from the 33 listed today. As the investigation is ongoing, and it doesn't look like any findings have been released at this point, there aren't really any new recommendations stemming from this breach. It just goes to show how far reaching the impact of a breach in a services provider can be. With all of the practices storing their data in 'the cloud', as provided by ECL, the risks for operators are higher, as are the rewards for black hats. Eye Care Leaders Hack Impacts Millions of Patients Eye Care Leaders EMR Data Breach Tally Surpasses 2 Million Breach at Eye Care Software Vendor Hits Millions of Patients | SecurityWeek.Com 5 more organizations added to Eye Care Leaders attack total, now biggest PHI breach of 2022 | SC MediaTETRA:BURST, MOVEit, and More - July 17th - 23rd, 2023 - F5 SIRT - This Week in Security
Editor's introduction Welcome back my friends, to the show that never ends. The editor carousel turns and it's me, MegaZone, again this week. Things are fairly busy currently, as we're coming up on our August 2nd QSN and we're doing all of our preparations for that. But there is still some time to look back at last week's news and pull out a few items that caught my attention. TWIS isn't necessarily the biggest issues of the week, of those with the greatest impact, or largest implications, etc. Just the issues that caught the eye of that week's editor, so each each reflects the personality of the editor to some degree as well. This time a fairly random mix of issues caught my fancy. TETRA involves a favorite subject of mine - rolling your own crypto. That's just a recurring bad idea. But I'm also interesting in seeing the technical details once they're released and just how broad the impact really is on today's users. MOVEit is this week's issue with the greatest potential impact, IMHO. Hundreds of organizations already identified as victims, over 20 million individual records suspected to be compromised - and that's likely just the tip of the iceberg given the organizations involved and the nature of their businesses. MOVEit could be one of the larger events of 2023, but we still have half the year left - it can always get worse. I used to be a regular Twitter user, but I really got tired of Elon's antics with it last fall and all but completely pulled stakes for the Fediverse. I've kept my account only to keep up with a couple of friends with private accounts who remain active there, and every time I check in it seems like things have gotten worse. So I admit to a bit of schadenfreude when I saw the article, and the data, on the massive decline in infosec Twitter activity earlier this year. Honestly, I'm glad to see more people leaving. But that's just me. I didn't always agree with Kevin Mitnick professionally, but I respected what he achieved. I was sorry to see the news last week of his passing from cancer at 59. I've lost friends and family to cancer, and my thoughts are with his family and those who were close to him. On that somber note, let's take a look back at the week that was. TETRA:BURSTs On the Scene As a teaser for an upcoming Black Hat presentation, some preliminary details on vulnerabilities in TETRA have been released. TETRA (TErrestrial Trunked RAdio) "is a digital trunked mobile radio standard developed to meet the needs of traditional Professional Mobile Radio (PMR) user organizations" - including public safety, utilities, transportation, and government and military operations. In use in over 100 countries, TETRA was developed nearly two decades ago and, wait for it, utilizes proprietary, closes cryptographic systems. cue montage of hands slapping foreheads That's invariably a ticking time bomb, and it seems TETRA is no exception. Never roll your own crypto. Five CVEs have been teased, though details have not yet been published: CVE-2022-24401- Critical: The Air Interface Encryption (AIE) keystream generator relies on the network time, which is publicly broadcast in an unauthenticated manner. CVE-2022-24402 - Critical: The TEA1 algorithm has a backdoor that reduces the original 80-bit key to a key size which is trivially brute-forceable on consumer hardware in minutes. CVE-2022-24404 - High: Lack of ciphertext authentication on AIE allows for malleability attacks. CVE-2022-24403 - High: The cryptographic scheme used to obfuscate radio identities has a weak design that allows attackers to deanonymize and track users. CVE-2022-24400 - Low: A flaw in the authentication algorithm allows attackers to set the Derived Cypher Key (DCK) to 0. Collectively, these vulnerabilities have been dubbed TETRA:BURST by the researchers at Midnight Blue. Stay tuned - they'll be presenting at Black Hat August 9th, with rapid follow-ups at Usenix Security on the 11th, and DEF CON on the 13th. https://tetraburst.com/ https://www.etsi.org/technologies/tetra https://www.vice.com/en/article/4a3n3j/backdoor-in-police-radios-tetra-burst https://www.theregister.com/2023/07/24/tetra_radio_security_flaws/ I Like to MOVEit! That's right, if my brain is going to earworm me every time I read this, I'm sharing it. With that out of the way, the MOVEit breach is turning into one of the largest cybersecurity incidents of the year. We've been seeing a lot of interest from our customers, so I know there is a lot of concern out there in the community. With reports continuing to surface it seems clear we'll have more than 500 victim organizations. It seems likely that it will be a while before the true scope of the impact is known; just how many organizations were hit, and how many millions of individuals have likely had their records breached. https://www.theregister.com/2023/07/20/moveit_victim_count/ https://www.cybersecuritydive.com/news/moveit-breach-timeline/687417/ https://therecord.media/more-companies-confirm-moveit-related-data-incidents-shutterfly-tjmaxx-tomtom InfoSec Twitter Is Dead Confirming what everyone who is actually part of the community already knew, the infosec community largely abandoned Twitter earlier this year - late-April to early-May, more precisely. I was actually an early departer - I'd had enough of Twitter's antics in late-2022 and headed over to the Fediverse, Infosec.Exchange in particular. But the data shows subsequent changes at Twitter have been quite effective at killing most of the remaining community. Over the last 3 weeks of our data (June 21 to July 12, 2023), we saw a weekday daily tweet count drop from the 1,272 pre-Elon average to just 333 tweets a day, which is about a 74% drop in weekday tweets. The 2-week rolling average (including weekends) dropped down to 272 tweets over the final 2 weeks. When I attempt to remove automated CVE announcements (bots), the drop is even more significant, dropping from over 500 a day down to 66 over the last two weeks, an 87% decrease in CVE-related tweets. This does explain an apparent uptick I noticed in infosec activity in the Fediverse in recent months. I suppose more people made the jump. https://www.cyentia.com/the-death-of-infosec-twitter/ https://www.scmagazine.com/news/researcher-flags-post-elon-data-showing-infosec-twitter-is-dead RIP, Kevin Mitnick I graduated from college in 1994 and got my first 'Internet' job with a long-since gone access server vendor, Xylogics, not long after. I'd already developed an interest in networks and security in school, and I was active on USENet back then, so of course I saw the news in early 1995 when Kevin Mitnick was arrested. The 'Free Kevin' movement was an early example of hacktivism, with corporate sites being defaced with the message, etc. His name kept popping up over the years during his trial and while serving his sentence, and then again with his release and new life in the infosec community. In my subsequent career I've seen him keynote and present multiple times over the years, I've run into him at tradeshows, etc. I think it is fair to say that he's been a controversial figure both within the infosec community with without, but he certainly was a prominent figure in the industry for the past couple of decades. Whether or not you agreed with his views, they had an impact simply because there were many who listened to what he had to say, and he had the voice of authority. Kevin had an outsized impact on our industry, in what is now a time cut short. Kevin Mitnick died Sunday, July 16th, 2023 aged 59, of pancreatic cancer, https://www.dignitymemorial.com/obituaries/las-vegas-nv/kevin-mitnick-11371668 https://blog.knowbe4.com/kevin-david-mitnick-aug-6-1963-july-16-2023 https://apnews.com/article/mitnick-hacker-ghost-wires-cybersecurity-social-engineering-5648301b615635cb4c781f0c220681d9 https://www.washingtonpost.com/obituaries/2023/07/20/kevin-mitnick-hacker-dies/ https://boingboing.net/2023/07/19/kevin-mitnick-1963-2023.html Until Next Time You can always check out past issues of This Week In Security. I also encourage you to explore the wider library of content published by the F5 SIRT. See you again in seven weeks, give or take.Cyber security 2024 summary and 2025 forecasts from the news
Notable security news for the week of Dec 22 nd – Dec 28 th 2024. This week editor is Lior from F5 SIRT. As always, when a year ends, security websites and vendors summarize the most significant security issues that happened over the past year. And with every end, there is a beginning. Enter 2025 cybersecurity predictions: what will happen this year in the world of cybersecurity? Here is what I summarized regarding the end of year 2024 and 2025 prediction in the cybersecurity landscape. 2024 cyber summary In 2024, the cybersecurity landscape was marked by significant incidents and evolving threats, with "more" being the keyword — more of everything. CVE details show a record number of 40,152 CVEs, around 10k more than last year. The CISA site - Known Exploited Vulnerabilities Catalog - shows significant growth in the actual exploitation of vulnerabilities. Large-scale incidents such as the Snowflake Data Breach, Salt Typhoon, and Fileless Malware, along with many other names that no one can really remember, have occurred. Then the true nature of software unexpectedly reveals itself, as seen in the CrowdStrike incident. One of the major breakthroughs in technology is the emergence of generative AI chatbot platforms, and as with any new technology, there is a need to secure it. Generative AI chatbots are becoming popular in web applications and are used to assist with specific, tailored actions relevant to users. These AI-driven chatbots use a wrapper on a commercial chat using APIs to operate, creating a whole new playground for attacks that now try to “convince” the chat to provide details it shouldn’t. Sounds familiar? totally familiar, but this time it is not XSS or SQLi; it is the LLM itself. Which is a great opportunity to mention the F5 AI Gateway. I guess we can consider 2024 as a year with unprecedented levels of security events (see my 2024 prediction more of everything). Enter 2025 So now you can ask yourself, will this continue in 2025 at the same growing rates? For sure! And will cybersecurity in 2025 be the year of AI security expansion? Beyond securing LLMs themselves, threat actors are expected to leverage artificial intelligence (AI) to enhance the sophistication of their attacks. This includes the use of AI for crafting more convincing phishing schemes, automating social engineering tactics, and deploying deepfakes for identity theft and fraud. But AI can also be used for protection and cyber defense: Integration of AI in Security Operations Centers (SOCs): AI is anticipated to play a central role in SOCs, automating tasks such as threat detection, vulnerability assessments, and incident response. Human analysts will focus on strategic decision-making and handling complex threats, enhancing overall operational efficiency. Security "co-pilots": AI-driven security operations centers (SOCs) will improve threat detection and automate incident response. Security controls assessment powered by AI: Using "AI Cyber Governance Platforms," AI will assist security personnel in understanding the real value of their security products and services, optimizing their arsenal to maximize protection. Agentic AI: Agentic AI is a software program designed to independently make decisions and take actions to achieve specific goals. Agentic AI is trending due to its ability to autonomously help CIOs realize their vision for generative AI to increase productivity. This all means that we are facing an even more intense year and as they say, "It is going to be interesting." Recommended reading: The Top 25 Security Predictions for 2025 New vulnerabilities While summarizing and doing prediction is nice exercise, the reality is that we have new vulnerability every week, here are two of them from last week: New critical Apache Struts flaw exploited to find vulnerable servers A recently patched critical Apache Struts 2 vulnerability tracked as CVE-2024-53677 is actively exploited using public proof-of-concept exploits to find vulnerable devices. Apache publicly disclosed the Struts CVE-2024-53677 flaw (CVSS 4.0 score: 9.5, "critical")” at Dec 11”, stating it is a bug in the software's file upload logic, allowing path traversals and the uploading of malicious files that could lead to remote code execution. "We are seeing active exploit attempts for this vulnerability that match the PoC exploit code. At this point, the exploit attempts are attempting to enumerate vulnerable systems," reports Ullrich. https://www.bleepingcomputer.com/news/security/new-critical-apache-struts-flaw-exploited-to-find-vulnerable-servers/ Palo Alto Releases Patch for PAN-OS DoS Flaw — Update Immediately Palo Alto Networks has disclosed a high-severity vulnerability impacting PAN-OS software that could cause a denial-of-service (DoS) condition on susceptible devices. The flaw, tracked as CVE-2024-3393 (CVSS score: 8.7), "A denial-of-service vulnerability in the DNS Security feature of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to send a malicious packet through the data plane of the firewall that reboots the firewall," the company said in a Friday advisory. Palo Alto Networks said it discovered the flaw in production use, and that it's aware of customers "experiencing this denial-of-service (DoS) when their firewall blocks malicious DNS packets that trigger this issue." https://thehackernews.com/2024/12/palo-alto-releases-patch-for-pan-os-dos.html https://security.paloaltonetworks.com/CVE-2024-3393 Podcasts recommendation Finally, I have listen to those podcasts in the past week and they are worth the time spending on. Podcast - Three Buddy Problem Palo Alto network edge device backdoor, Cyberhaven browser extension hack, 2024 research highlights. https://securityconversations.com/episode/palo-alto-network-edge-device-backdoor-cyberhaven-browser-extension-hack-2024-research-highlights/ F5 DC : Announcing the new 'AI Friday' Podcast - Episode 1 Our own F5 folks talk about AI in a new podcast. Great job, looking forward for the next chapter. https://community.f5.com/kb/technicalarticles/announcing-the-new-ai-friday-podcast---episode-1/338527 See you all next year.
