In the latest incarnation of the TLStorm vulnerability, switches from Avaya and Aruba — and perhaps others — are susceptible to compromise from an internal attacker.

Network switches from Aruba and Avaya are vulnerable to multiple flaws that could allow attackers to remotely execute code and completely take over the devices.

Researchers from device-intelligence firm Armis found five vulnerabilities — two flaws in Aruba switches and three flaws in Avaya switches — that could be used to compromise networks that allow some outsider access, even with limited rights. The flaws can be exploited by a user of a captive portal or authentication server, researchers explained.

Worryingly, in looking at the details of the bugs, the three Avaya bugs are zero-click, requiring no authentication or user interaction to exploit. One of them affects an end-of-life device and won't be receiving a patch.

Three of the vulnerabilities originate with improper handling of errors produced by a third-party library for implementing TLS produced by Internet of Things (IoT) cybersecurity firm Mocana.

Because switches are typically not Internet-facing, the vulnerabilities face less danger from external hackers, but the risk is still significant, says Barak Hadad, head of research for Armis.

"These are major issues, because switches act as the gatekeepers when we talk about segmentation," he says. "When you gain control over switches, any segmentation of the network becomes invalid."

The vulnerability details are as follows:

Aruba:

*   CVE-2022-23677 (9.0 CVSS score) — NanoSSL misuse on multiple interfaces (RCE)\*
*   CVE-2022-23676 (9.1 CVSS score) — RADIUS client memory corruption vulnerabilities

Avaya:

*   CVE-2022-29860 (CVSS 9.8) — TLS reassembly heap overflow\*
*   CVE-2022-29861 (CVSS 9.8) — HTTP header parsing stack overflow
*   HTTP POST request handling heap overflow (no CVE because it is in an older version)\*

\* These are caused by the interaction between Mocana NanoSSL and the products.

**Software Supply-Chain Woes Persist**  
The vulnerabilities underscore the risks of the software supply chain and the potential dangers that come with using third-party components. Security flaws in the libraries on which software depends — or in this case, in the way that the software and library interact — can create or propagate vulnerabilities. On average, 78% of software codebases consist of open source components and libraries.

In March, researchers discovered a similar set of flaws that caused security vulnerabilities in more than 150 IoT products, also caused by another third-party component.

"While the use of external libraries has many advantages, it also brings inherent uncertainty," Armis stated in its security advisory published on May 3. "Implanting a 'foreign' code means the vendor is trusting it to be implemented safely, since any security issues originating in the external library are embedded within it, and automatically become security issues which the vendor has less control over."

**TLStorm, Part 2**  
At the heart of the Mocana-related vulnerabilities are unstable error states in the Mocana NanoSSL library that handles transport layer security (TLS) for the products' management interface.

The issues occur because the attacker can craft network packets that cause errors in the Mocana NanoSSL library, and developers producing software for vendors do not handle the errors properly.

The result are two classes of vulnerabilities: memory corruption and state confusion.

"If you start a TLS handshake and the other side sends an improper message, if you don't check the error code correctly, that scenario can be leveraged to gain remote code execution in some cases," Armis' Hadad says. "The manual clearly says that the developer should check the error, but as we know, it's not common for developers to read through the entire manual."

Armis has worked with Mocana, Aruba, and Avaya to remediate the issues where appropriate. The companies' customers have been notified, and each company has released updated software. In Mocana's case, even though the vulnerabilities are not technically caused by the software, the company has created an update anyway to avoid future flawed implementations.

"It is not a Mocana vulnerability, but nonetheless, they have published new software that makes it so you are not in a vulnerable situation just because you did not check the error code," Hadad says.

The vulnerabilities, dubbed TLStorm 2.0 by Armis, are similar to ones announced in March that affect smart-connected uninterruptible power supplies (UPS).

**Not the First Flawed implementation**  
Previously, Armis researchers showed the same vulnerabilities used against several models of UPS from APC, now owned by Schneider Electric. The attacks, which targeted UPS that connected to the Schneider Electric Cloud to enable management, could allow attackers to remotely compromise devices without any user interaction or leaving any trace of the attack.

Because new firmware could be loaded into the devices remotely, attackers could change the waveform and voltage of the AC power provided to connected devices and even cause the UPS to overheat.

"The fact that UPS devices regulate high voltage power, combined with their Internet connectivity — makes them a high-value cyber-physical target," Armis stated in its March advisory regarding the vulnerabilities, which it called TLStorm. "Since the TLS attack vector can originate from the Internet, these vulnerabilities can act as a gateway to the internal corporate network. Bad actors can use the TLS state confusion to identify themselves as the Schneider Electric cloud and collect information about the UPS behind the corporate firewall."

TLS Flaws Leave Avaya, Aruba Switches Open to Complete Takeover

The security vulnerability payout set bug hunters rejoicing, but claiming the reward is much, much easier said than done.

Google has expanded its bug-bounty program to offer a whopping $1.5 million for a top-notch Android 13 Beta exploit – specifically, for a hack of the Titan M security chip that ships with Pixel phones.

Android 13 Beta became available last week to developers and early adopters, with Google promising an outsized focus on privacy and security. It apparently aims to deliver in that department, if the bounty bump is any indication.

The Internet giant announced a 50% bonus for all Android 13 Beta exploits on Twitter and updated its Android program page to reflect the offer, adding an important caveat: "Vulnerabilities must be exclusive to Android 13 and must not reproduce on any other version of Android," it noted.

To take advantage of the largess, bug hunters will need to set off on safari soon: The increased rewards are only good for reports filed before May 27.

**Putting the $1.5M Payout into Context  
**For a sense of perspective on that payout number, it's worth noting that $1.5 million is exponentially larger than the highest-ever bounty for an Android vulnerability, which was paid last year — $157,000 for a critical exploit chain in an unspecified component. It's also half the amount paid out in the entirety of 2021 for Android flaws ($3 million total, across hundreds of exploits), and roughly equal to the sum total of payouts in 2020. So, this is a lot of love for one bug.

That said, the likelihood of seeing a payout that size is a long shot. That's because it would be connected to the last time Google dabbled in big-bucks territory: In 2019, it began offering $1 million to anyone who could hack the Titan M security chip, which is embedded in Google Pixel smartphones. Specifically, it requires a "full chain remote code execution exploit with persistence, which compromises the Titan M secure element on Pixel devices."

But so far, that reward has gone unclaimed. Thus, to reel in the $1.5 million on offer, an ethical hacker would need to not only subvert the never-subverted Titan M, but also make sure the exploit works on Android 13 Beta – and only on Android 13 Beta.

The difficulty scale hasn't deterred some. As one bounty hunter tweeted, "BRB going to sell my soul to the hacker gods to get a full remote code execution exploit chain on the Titan M."

**All Android 13 Beta Exploits Get a Bump  
**Google's other rewards for finding an exploitable security vulnerability in Android are also subject to the 50% bonus for Android 13 Beta. Those run anywhere from $75,000 (for a Device Policy Controller bypass or code execution in a privileged process) to $500,000 (for exfiltrating high-value data secured by Titan M). Most rewards clock in at $250,000.

OEM code (libraries and drivers), Digital Car Keys, kernel, boot-loader, Secure Element code, TrustZone OS and apps, system on chip (SoC), MicroController Unit (MCU), Boot ROM, RAM memory, Flash memory, filesystem, Trusted Execution Environment (TEE), radio units, etc., are all considered eligible targets.

Google Offers $1.5M Bug Bounty for Android 13 Beta

CERT-In updates cybersecurity rules to include mandatory reporting, record-keeping, and more.

The Indian Computer Emergency Response Team (CERT-In) issued new cyber incident reporting guidelines, including the requirement for service providers, intermediaries, data centers, corporations, and government agencies to report cyber incidents to the regulator within six hours.

The new government-issued cybersecurity rules will take effect in 60 days.

Incidents requiring immediate CERT-In notification include:

*   Targeted scanning/probing of critical networks/systems
*   Compromise of critical systems/information
*   Unauthorized access of IT systems/data
*   Defacement of website or intrusion into a website and unauthorized changes such as inserting malicious code, links to external websites, etc.
*   Malicious code attacks such as spreading of virus/ worm/ Trojan/ bots/ spyware/ ransomware/ cryptominers
*   Attack on servers such as database, mail, and DNS, and network devices such as routers
*   Identity theft, spoofing, and phishing attacks
*   Denial of service (DoS) and distributed denial of service (DDoS) attacks
*   Attacks on critical infrastructure, SCADA and operational technology systems, and wireless networks
*   Attacks on applications such as e-governance, e-commerce, etc.
*   Data breach
*   Data leak
*   Attacks on Internet of Things (IoT) devices and associated systems, networks, software, and servers
*   Attacks or incident affecting digital payment systems
*   Attacks through malicious mobile apps
*   Fake mobile apps
*   Unauthorized access to social media accounts
*   Attacks or malicious/ suspicious activities affecting cloud computing systems/ servers/ software/ applications
*   Attacks or malicious/suspicious activities affecting systems/ servers/ networks/ software/ applications related to big data, blockchain, virtual assets, virtual asset exchanges, custodian wallets, robotics, 3D and 4D printing, additive manufacturing, and drones
*   Attacks or malicious/ suspicious activities affecting systems/ servers/software/ applications related to artificial intelligence and machine learning

Other new rules require service providers and their intermediaries, data centers, corporations, and government agencies to connect to the Network Time Protocol (NTP) server of the National Informatics Center (NIC) or National Physical Laboratory (NPL) — or with servers that can be traced back to one of those two servers — and synchronize their ICT system clocks with the government's.

These organizations will also need to start keeping logs for the previous 180 days and provide it to CERT-In if an incident occurs, the new guidelines said.

The tightening up of reporting rules is intended to close "certain gaps causing hinderance in incident analysis," the Ministry of Electronics & IT said in its statement announcing the new cybersecurity measures. "These directions shall enhance overall cyber security posture and ensure safe and trusted Internet in the country."

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

New Regulations in India Require Orgs to Report Cyber Incidents Within 6 Hours

A California man faces prison time and steep fines stemming from cybertheft of US military funds intended to pay jet-fuel suppliers.

The Department of Justice has announced a conviction on six counts against a California man who stole more than $23 million from the Department of Defense with a phishing scam. 

Northridge, Calif.-based cybercriminal Sercan Oyuntur, along with co-conspirators from Germany, Turkey, and New Jersey, targeted suppliers of jet fuel to US troops in Southeast Asia. The goal was to intercept payments from the DoD, according to the the US Attorney's Office in the District of New Jersey.

It said in an announcement about the court win that after creating email accounts and standing up a spoofed General Services Administration website, the threat actors sent phishing emails to try and trick vendors into giving up their login credentials. The cyber crooks then used those to divert payments to their own accounts. 

Oyuntur pleaded guilty and will be sentenced on June 21. The two conspiracy and bank fraud counts could come with a sentence of up to 30 years, along with steep fines, the DoJ said. 

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

DoD Scammed Out of $23M in Phishing Attack on Jet-Fuel Vendors

Security must be precise enough to meet compliance requirements without impeding DevOps and developer productivity. Here's how to strike that balance.

Businesses are moving fast to modernize application development, but Kubernetes security has taken a back seat in many cases. While that deprioritization is increasingly risky, security strategies to mitigate threats to containerized environments must tread a careful path.

On the one hand, security must be precise enough to meet the rigorous compliance requirements — and stand up to audits — across all regulations a given organization must adhere to, whether that's SOC 2, PCI DSS, GPDR, HIPAA, or others. At the same time, whatever security processes are put into place must still ensure that DevOps and developer productivity isn't impeded. It's a delicate balancing act that doesn't leave much room for error on either side.

To ensure continuous compliance in containerized environments without creating obstacles to productivity, adhere to these six practices.

**1\. Get Automated**  
Implementing the right tools — and there are many great fully open source options — delivers the real-time threat responses and always-on monitoring necessary for achieving continuous compliance. For example, automated vulnerability scanning and security policy as code should be integrated into the pipeline. Logs and events should be processed with an automated Kubernetes audit log analyzer. SIEM technologies powered by machine learning can quickly and automatically identify attack patterns. You should also leverage CIS benchmarks and custom compliance checks to inspect Kubernetes configurations continuously.

**2\. Secure Kubernetes Itself**  
It's become absolutely crucial to treat Kubernetes itself as an attack surface — because attackers certainly are. With the sophistication of threats maturing, continuous compliance now requires that the full stack behind your container environments is actively secured. This includes initiating automatic monitoring, hardening against exploits, performing configuration auditing, and preparing automated mitigation. That's not only true for Kubernetes but also any service meshes, hosting VMs, plugins, or other targets that may come under attack.

**3\. Seeing an Attack Is Preventing an Attack**  
Attack kill chains often begin with the launch of an unrecognized container network connection or process, which escalates its own level of access by writing or changing existing files or exploiting unprotected entry points. Such nefarious methods will then utilize network traffic to send captured data to an external IP address, resulting in a data breach. Kill chains may similarly target the Kubernetes API service for man-in-the-middle attacks, and commonly perform zero-day, insider, and cryptomining attacks. Attacks leveraging the Apache Log4j exploit are also on the rise.

Strategies that incorporate data loss prevention (DLP) and web application firewall (WAF) protection can provide the visibility required to detect active kill chains, as well as automated responses ready to put suspicious processes and traffic to a halt before they do harm. In fact, many regulatory compliance frameworks now specifically require organizations to have DLP and WAF capabilities in place to protect their container and Kubernetes environments, including PCI DSS, SOC 2, and GDPR (HIPAA strongly suggests DLP as well).

**4\. Zero in on Zero Trust**  
By implementing a zero-trust model, you're no longer _reactively_ addressing threats recognized in log analysis or signature-based detections. Instead, a zero-trust strategy ensures you'll be blocking all attacks by allowing only approved processes and traffic to be active in your environments. The full cloud-native stack, along with access controls such as RBACs, must feature these zero-trust safeguards. The result is a more assured approach to achieving continuous compliance.

**5\. Take Advantage of Built-In Kubernetes Security**  
Built-in Kubernetes security features include log auditing, RBACs, and system log collection centralized by the Kubernetes API server. Leverage these available capabilities to collect and analyze all activity logs for evidence of attack or misconfigurations. Follow up by addressing any issues or run-time activities that fall short of compliance by implementing security patches or new policy-based protections.

In most cases, you'll want to go further and support existing Kubernetes security with tooling that enables container application security and continuous compliance auditing. The built-in Kubernetes Admission Controller should be used to closely coordinate Kubernetes with external registries and resource requests. This approach will more effectively prevent vulnerabilities and unauthorized behavior in application deployments.

**6\. Verify the Security of Your Cloud Host**  
Cloud platforms hosting Kubernetes handle their own systems and must ensure their continuous compliance. However, the stakes are too high not to check that those cloud hosting practices are indeed well-secured and that they fulfill your own compliance responsibilities. In fact, the shared responsibility model offered by many cloud providers leaves the burden of securing application access, network behavior, and other assets in the cloud squarely on the customer.

**Continuous Compliance in Real-Time Environments**  
Kubernetes and containerized environments are highly dynamic, with containers spinning in and out of existence far more rapidly than manual security checks can possibly safeguard. In addition, traditional security technologies such as network segmentation and firewalling required by many compliance regulations don't work in container networks.

Modern continuous development processes regularly introduce new code and containers as applications are built, shipped, and run in production environments. As a result, regulations require organizations to adopt automated real-time security and auditing measures that provide true continuous compliance.

6 Best Practices to Ensure Kubernetes Security Meets Compliance Regulations

Come up with a clever caption, and our panel of experts will reward the winner with a $25 Amazon gift card.

A few potted plants around the workplace may make for a pleasant environment, but could this employee be taking that notion a bit too far? Therein lie the seeds for The Edge's latest caption content. Come up with a security-themed caption for your chance to win a $25 Amazon gift card. We offer four convenient ways for you to send us your ideas:

*   Email _\[email protected\]_ with the subject line "The Edge May 2022 Toon."
*   Via social media: Twitter, Facebook, and LinkedIn_._

The contest closes on Wednesday, May 25, 2022.

**Last Month's Winner**  
Last month's contest, "In Deep Water," stoked the imaginations of many Dark Reading readers. But in the end only one person can win, and this time the honors go to Braedon Gerdes, whose caption appears below:   

    

Congratulations, Braeden. Your gift card is on the way. And thanks to everyone who participated. We can't wait to see what you come up with next.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Name That Edge Toon: Flower Power

Breaches can happen to anyone, but a well-oiled machine can internally manage and externally remediate in a way that won't lead to extensive damage to a company's bottom line. (Part 1 of a series.)

Wise security professionals understand that threat actors aren't sitting still, and they aren't playing by the same rules as old-school groups. Lapsus$, for example, is gaining notoriety for its unpredictable behavior, using tactics like extortion and bribing insiders for initial access. It has left even the most experienced security pros scratching their heads.

When you find your organization has been breached, will you be scrambling to figure out your security incident response and remediation plan when your team can't think straight, or will your response be as simple as muscle memory? To minimize the damage done when a security incident occurs, it's important to look inward.

**Keep a Tight Ship  
**I would never dare promise to "eliminate cyber threats," but I can provide strong recommendations to improve internal security. Analyzing some of the latest Lapsus$ victims, we can learn a few things.

First, **_credential security is imperative._** Sooner or later, a threat actor will compromise credentials in your organization. It's not realistic for a business to expect all employees to refuse extortion attempts at all costs. Understanding this reality turns the impossible task into a practical solution.

Security teams should shift their focus from purely _preventing_ credential compromise to _tracking_ user behavior so that anomalies can be quickly identified and acted upon.

Lastly, when discussing the Lapsus$ incidents and others like them that are using extortion and bribery to initiate entry, we must discuss the importance of cybersecurity awareness and insider threat training. Many organizations have put some level of end-user security training into practice. But clearly, that isn't enough to stop novel threat groups from breaching the last line of defense.

**Managing Third-Party Companies  
**Organizations can't prepare their own privacy and security practices in a vacuum — we all depend on a large network of products and services to do our jobs.

Repeat after me: _Anyone (or any organization) could easily be a victim of a third-party incident._

If you were to assess the privileges of each of your third-party solutions, would you be proud of what you found? Chances are, there are weak spots in access protocols. Your third-party solutions likely have access to things they shouldn't. Your contractual agreements probably aren't bulletproof either.

While it's important to factor in the balance of manageable risk with return on investment, it's also essential to foster a collaborative yet vigilant relationship with all of your external parties. It's about defining a clear contract with vendors that involves security early on, focusing on shared responsibilities for security, good architecture, and timely communication.

**Check on Cybersecurity Checklists  
**Creating a cybersecurity checklist should be a requirement to do business with any third party. The checklist should include (but is not limited to): thoroughly vetting vendors' privacy and security standards; adding terms and conditions within your contract to address what would happen in the case of an outage and the costs each party would incur; and contingency plans for employees who may depend on technology or software solutions to do their jobs. Take a similar approach whenever your organization is involved in any type of M&A activity, as the risks apply to those scenarios as well.

There will always be risks associated with third-party solutions, but living in a bubble isn't realistic. Managing this risk by having visibility and security capabilities across the entire security incident response life cycle must be the endgame.

**Communicating Gaps  
**Organizations experiencing a security incident must not hide behind a third party and shouldn't blame their employees. They also must not allow lawyers to create smokescreens around what happened. This helps no one in the long term and only saves face until it doesn't anymore.

Communication around current vulnerabilities and threats is constantly flowing in healthy, well-prepared organizations. As a security practitioner, you should be proactive in how you communicate with leadership. It's extremely effective to manage up by sending a notice to leadership about a new breach or vulnerability with your insight added. Security analysts can offer value by proactively showing that they've already checked "XYZ" and that they're running automated queries for indicators of compromise, etc. They can forward that to their CISO for that person to share upward. CISO/SOC leadership can then take action to fill that gap.

Additionally, when a security incident occurs, security analysts should feel comfortable saying "we didn't have the capabilities to identify this incident." Effective operations require reflection on your own security incidents and thought experiments with other shared problems in the security community. Be honest and document everything. From there, they can use these proof points to work with leadership and fill in the gaps.

**Culture Is Key  
**No one with a straight face can deny the importance of security culture when it comes to keeping a tight ship, managing third-party security, and mastering internal communication. Culture weaves through it all. Motivated employees with excellent support from their team members and leadership are less likely to make errors and are also less likely to turn around and give information to a cybercriminal when faced with the temptation of shiny rewards or, worse, revenge.

Fostering a culture of open communication (as opposed to fear of making a mistake) will help your security analysts feel like they can talk to leadership about what gaps need to be filled to properly do their jobs and minimize the impact of future breaches.

Security incidents will happen to everyone, but a well-oiled machine can internally manage and externally remediate in a way that won't lead to extensive damage to a company's bottom line. Many companies are overwhelmed with just the thought of a breach happening — imagine how they panic when a breach actually occurs.

_Stay tuned for Part 2 later this week, which will provide advice on handling the public's response after an incident._

Security Stuff Happens: What Do You Do When It Hits the Fan?

A comprehensive security strategy balances technology, processes, and people — and hiring and retaining security personnel and securing the remote workforce are firmly people priorities.

Almost five months into 2022, acquiring and retaining security personnel and securing the remote workforce are two things top of mind for security leaders.

That's according to analyst firm Info-Tech Research's 2022 Security Priorities report, which lays out both the top priorities and the main obstacles for security leaders. The other three top priorities are digital transformation, zero trust, and ransomware. The priority list is strongly influenced by the COVID-19 pandemic, the increase in cybercrime, and the shift to remote work, according to Info-Tech Research.

Nearly a quarter of the respondents (23%) named securing the remote workforce as their top priority for 2022. That includes both implementing security controls to create a secure environment for users and helping employees build "safe habits," the research firm said.

    

Source: Info-Tech Research

Pandemic-driven changes like the shift to remote work "are largely expected to remain, regardless of the progression of the pandemic itself," Info-Tech Research said in its report. This is consistent with Dark Reading's 2022 Endpoint Security Survey, where 48% of respondents said they made changes to their endpoint security strategy to accommodate the shift to work-from-home in the early days of the pandemic — and 54% don't plan on shifting back to how things were before the pandemic.

Along with remote workforce security, the other top priority in the people category was hiring skilled cybersecurity professionals and creating a good working environment for existing employees. Retention is very important, as being understaffed means new security initiatives are placed on hold and existing security projects may be delayed. In fact, 31% of respondents cited staffing constraints as their biggest obstacle.

"The pandemic has changed how people work as well as how and where they _choose_ work," Info-Tech Research found, noting that "Most smart, talented new hires in 2022 are demanding to work remotely most of the time."

This create a bit of a tangle for security leaders, who want to attract top talent by giving them the flexible work environment they are asking for, but the shift to remote work exposes organizations to more costly cyber incidents, according to Info-Tech Research. The cost of a data breach rose by nearly 10% over the past year, with the average cost at $4.24 million, Info-Tech Research said, citing figures from IBM's Cost of a Data Breach report. The average cost of breaches where remote work is involved is $1.07 million higher, suggesting that ubiquitous remote work will continue to result in more costly security incidents.

Part of the reason for the higher costs may be because "it takes two months longer, on average, to detect and contain a breach when more than 50% of staff are working remotely," the report said, citing IBM.

Security leaders need to reassess the enterprise security strategy to consider the work-from-home attack surface, especially endpoint visibility, and to enable strong authentication requirements, such as multifactor authentication (hardware tokens for high-risk users) and VPNs for restricted sessions.

With remote work, it is even more imperative that security leaders develop a zero trust strategy in order to minimize the blast radius in case of a breach. Zero trust, coincidentally, happens to be one of the top security priorities, which we'll cover next week.

2022 Security Priorities: Staffing and Remote Work

The less-good news: IAM only works for applications your IT department knows about, so watch for "shadow IT" programs installed or written by users that leave a security gap.

Almost every company implements identity access management (IAM) techniques such as single sign-on (SSO) to secure users who access software-as-a-service (SaaS) offerings, and most supplement that with measures like firewalls and cloud access security brokers (CASBs).

That's according to the 2022 SaaS Visibility and Impact Report from SaaS security provider Torii, which surveyed 100 technology executives to see how the pandemic has affected their IT practices and strategies. Nine of out 10 respondents (90%) say they use IAM/SSO to protect their networks, with 70% adding firewalls, antivirus software, and related safeguards. More than 6 out of 10 (61%) implement CASB or other security access guardrails related to secure access service edge, while 16% use SaaS management tools.

SaaS has become an indispensable part of business, especially during the pandemic-impelled push toward remote working. In the recent Dark Reading survey State of the Cloud: A Security Perspective, for example, half of respondents reported having 2 to 9 cloud applications in their organization. This new reality creates a need for tools that protect network resources: A recent study from Reposify showed that almost two-thirds of cybersecurity vendors had their back-office networks directly accessible from the Internet, and half had at least one exposed database.

An extra challenge springs from the decentralized work environment. Employees have started to solve their own problems by writing or installing their own software tools outside of the control of the IT department, a phenomenon known as "shadow IT." These programs, while often useful for solving immediate challenges, can create security holes when IT doesn't even know the tool exists.

Both CASBs and SaaS management tools can plug up shadow IT holes, while IAM and firewalls tend to be blind to uncatalogued software. For more, read the full report here.

Keep up with the latest cybersecurity threats, newly-discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

Subscribe

Good News! IAM Is Near-Universal With SaaS

QNAP and Synology say flaws in the Netatalk fileserver allow remote code execution and information disclosure.

Network attached storage (NAS) device vendors QNAP and Synology this week disclosed multiple critical vulnerabilities in an open source fileserver technology integrated into their products.

The vulnerabilities — several of which enable remote code execution (RCE) — exist in Netatalk, an open source version of Apple File Protocol fileserver for accessing network shares in multiple operating system environments. Both vendors are still working on updating all versions of their products that contain the vulnerability.

**Unpatched for Months**  
Security researchers working in coordination with the Zero Day Initiative (ZDI) reported a total of six vulnerabilities to the maintainers of Netatalk in December. Three of them are critical RCE bugs tied to buffer-overflow issues (CVE-2022-0194; CVE-2022-23122; CVE-2022-23125). Two of the flaws are medium-severity out-of-bounds information-disclosure vulnerabilities (CVE-2022-23124; CVE-2022-23123), and one is a critical RCE issue tied to improper handling of exceptional conditions (CVE-2022-23121).

Brian Gorenc, senior director of vulnerability research and head of ZDI at Trend Micro, tells Dark Reading that all the Netatalk bugs were first discovered at Pwn2Own Austin in November 2021.

Another flaw, a high-severity buffer-overflow related RCE (CVE-2021-31439), was disclosed to Netatalk's maintainers all the way back in March 2021.

The development team at Netatalk released an updated version of the software (Netatalk 3.1.13) on March 23 that addressed all seven of the vulnerabilities. The updated version is available for all currently supported operating systems: FreeBSD, Linux, OpenBSD, NetBSD, and Solaris and derivates.

However, it's a longer timeline for some vendors to roll the patches into their products. ZDI's Gorenc says that because Netatalk is a third-party component used by many NAS vendors, the vendors are responsible for monitoring for releases of Netatalk and integrating these releases into their products. "We are glad to see the NAS vendors updating their Netatalk deployments to resolve the vulnerabilities that were disclosed and fixed at Pwn2Own Austin," he says.

Western Digital is another vendor whose products were impacted by the flaws in Netatalk. But unlike Synology and QNAP, Western Digital proactively removed Netatalk from its products on Jan. 10, 2022, citing concerns over multiple critical vulnerabilities in the technology.

"Because Netatalk is unmaintained, we have removed Netatalk from our firmware released on January 10, 2022," the company announced in March. "Users can continue to access local network shares and perform Time Machine backup via SMB."

**Affected Devices**  
Synology's advisory described the vulnerabilities as critical and allowing remote attackers to steal sensitive data. Bad actors could potentially execute arbitrary code on NAS devices via a vulnerable version of its DiskStation Manager (DSM) and Synology Router Manager (SRM) technologies.

QNAP identified multiple versions of its QTS operating system as being vulnerable and said it is currently investigating the flaws. The company said that it's working on releasing updates to all impacted products, and it urged customers to install the updates as soon as they become available.

The Taiwan-based NAS manufacturer also outlined steps that organizations can take to mitigate the risk posed by the vulnerabilities while it works on fixes. QNAP's advisory identified CVE-2021-31439 — the flaw from last March — as one of the issues that it still needs to address in its products even though it was disclosed more than one year ago.

Both Synology and QNAP did not immediately respond to requests for comment from Dark Reading.

Source

DARKReading