Single sign-on and request smuggling to the fore in another stellar year for web security research

Adam Bannister 10 February 2023 at 14:56 UTC  
Updated: 10 February 2023 at 16:10 UTC

Single sign-on and request smuggling to the fore in another stellar year for web security research

Detectify founder Frans Rosén has topped PortSwigger’s top 10 web hacking techniques of 2022 with ‘Account hijacking using dirty dancing in sign-in OAuth-flows’.

Published in July, the research was hailed as “a masterclass in chaining OAuth quirks with low-impact URL-leak gadgets including promiscuous postMessages, third-party XSS, and URL storage” by PortSwigger director of research James Kettle in a blog post announcing the results on Wednesday (February 8).

“Many of these bugs would previously have been dismissed as having no significant security impact, so they’ve had years to proliferate,” Kettle added.

DON’T MISS Top 10 web hacking techniques of 2022

The researcher praised Rosén for producing an “outstanding piece of research that we expect to yield fruit for years to come”.

Rosén told The Daily Swig: “I am really thankful and humble ending up on first place among so many great researchers and their awesome posts during the year.

“One thing that I did different this year was to start digging into a subject without even having a single bug to start with. It was only just an idea of a potential concept.

READ MORE ‘Dirty dancing’ in OAuth: Researcher discloses how cyber-attacks can lead to account hijacking

“Thanks again to PortSwigger for highlighting the people in the industry publicly disclosing their findings and methodologies – that’s in my opinion one of the best ways to move the industry forward.”

Rosén was declared the winner by a panel of his peers comprising Nicolas Grégoire, Soroush Dalili, Filedescriptor, and Kettle.

**A new frontier in HTTP request smuggling**

Kettle himself claimed silver medal for the second year in a row, as well as sixth place for separate, HTTP header injection research showcased at Black Hat USA (note: panellists could not vote for their own research).

After claiming second place in the 2021 rankings with ‘HTTP/2: The Sequel is Always Worse’, this time the researcher impressed by leveraging novel HTTP request smuggling vectors to compromise targets including Amazon and Apache “and ultimately taking the attack client-side into victim's browsers”.

RELATED Browser-Powered Desync Attacks: A New Frontier in HTTP Request Smuggling

Described as “seriously technically challenging” research, ‘Browser-Powered Desync Attacks’ prompted one judge to enthuse: “The creativity from desync worm (reminiscence of XSS worm) to client-side desync is off the chart”.

Kettle envisages request smuggling’s multi-year run of being a rich source of novel threats to continue until “until HTTP/1 has been fully stamped out”.

**Memcache injection and Zimbra**

In third place, Google’s Simon Scannell found a memcached injection vulnerability in business webmail platform Zimbra that allowed attackers to poison an unsuspecting victim’s cache and steal cleartext credentials.

READ MORE Business email platform Zimbra patches memcached injection flaw that imperils user credentials

Kettle said the research, which also deployed request smuggling, demonstrated the value of having “deep knowledge of a target”.

Scannell, then of Swiss outfit Sonar, wrote in his research: “By continuously injecting more responses than there are work items into the shared response streams of Memcached, we can force random Memcached lookups to use injected responses instead of the correct response.”

**‘Pushing at the boundaries’**

The 16th annual edition of PortSwigger’s top 10 web hacking techniques saw a record 46 nominations initially whittled down to 15 final-round candidates based on votes cast by the infosec community.

Kettle noted that “outright novel techniques and class-breaks have gotten rarer” but said more researchers were “pushing at the boundaries and sharing their findings than ever”.

Here’s the rest of the top 10 in brief (read James Kettle’s post for a deeper breakdown):

*   4\. ‘Hacking the Cloud with SAML’ by Felix Wilhelm culminates with an XML document leveraging an integer truncation bug to trigger arbitrary bytecode execution when Java attempts to verify its signature
*   5\. ‘Bypassing .NET Serialization Binders’ by Markus Wulftange resulted in vulnerabilities in DevExpress framework and Microsoft Exchange that opened the door to remote code execution
*   6\. ‘Making HTTP header injection critical via response queue poisoning’ by James Kettle explored “the long-forgotten response-splitting technique with a high-impact, high-payout case study”
*   7\. ‘Worldwide Server-side Cache Poisoning on All Akamai Edge Nodes’ by Jacopo Tediosi leveraged HTTP hop-by-hop headers to earn – with some triaging difficulty along the way – a raft of bug bounties
*   8\. ‘Psychic Signatures in Java’ by Neil Madden used the number 0 to forge ECDSA signatures and upend the cryptographic foundation of core web technologies such as JWT and SAML
*   9\. ‘Practical client-Side Path Traversal Attacks’ by Medi highlights a “visible” but neglected issue that should now be recognized “as a vulnerability in its own right”
*   10\. ‘Exploiting Web3’s Hidden Attack Surface: Universal XSS on Netlify's Next.js Library’ by Sam Curry compromises various cryptocurrency sites with XSS, SSRF, and cache poisoning originating from Netlify's Next.js library

PREVIOUS EDITION Dependency confusion tops the PortSwigger annual web hacking list for 2021

OAuth ‘masterclass’ crowned top web hacking technique of 2022

In the cloud-first world, the security goal is to ensure only qualified users can access information across clouds.

The rise of multicloud environments brings with it the need to understand how to implement security policies across each cloud provider. The fact that each of the big three — Amazon Web Services (AWS), Microsoft Azure, and Google Cloud Platform (GCP) — uses different nomenclature and configurations makes it that much more complicated to create a seamless and secure virtual network.

A pair of researchers shared their practical advice on how to secure one piece, identity and access management (IAM), at Black Hat USA 2022.

"If there is one thing we would like you to take from this specific session, it is that IAM is the backbone service. It is the core service. It is the gateway that controls every access to your cloud resources, and it must be protected," said Igal Gofman, Ermetic's head of security, who presented "IAM the One Who Knocks" with Noam Dahan, Ermetic's research lead.

**Multiple Strategies for Multiple Clouds**

Organizations have several reasons for using multiple clouds, as Gofman listed off: adding in redundancy for better stability, reducing costs, taking advantage of multiple vendors' marquee features, and having conflicting platform requirements from different projects. But when you split resources among various clouds, he added, you need to be aware of and accommodate for the differences between how the platforms function.

"It's hard enough to be an expert on one cloud platform," Gofman said. "But often we copy features and routines from one platform to another. And those may work differently from what we expect at the beginning."

Dahan then drilled down on the ins and outs of logging features from Azure, AWS, and GCP. Besides using logging for detection and incident response, he said it is good for improving the permissions process.

"In order to know whether you can take permissions away from someone, what you would usually do is try to examine the logs and see what they're actually using, a sort of 'use it or lose it' philosophy," he explained.

There are two main approaches to issuing permissions, Dahn said: sculpting from marble or sculpting from clay. Marble means starting with a full raft of permissions and then chipping away until you reach minimum necessary permissions; this can end up too permissive because you don't want to remove too much. Clay means building up permissions until you have enough. Security staff likes this model, Dahan said, but developers hate it because they don't know what permissions they will need down the road. He recommended a hybrid approach of starting with a smaller hunk of permissions and then building up in places as needed.

**Who's at the Door?**

The title of the talk comes from the TV series _Breaking Bad_, when science-teacher-turned-meth-kingpin Walter White reacts to a friend warning him that he's in danger of someone coming to his door and killing him. White, incensed, asserts that he is the dangerous one by saying, "I am the one who knocks." Perhaps IAM is the stand-in for White — it looks basic and unassuming, but underestimating its power is dangerous. Or maybe it's just a turn of phrase.

Building Up IAM in a Multicloud World

Five months after AWS customers were alerted about three vulnerabilities, nearly none had plugged the holes. The reasons why underline a need for change.

It's a familiar story: A feature designed for convenience is used to sidestep security measures. In this presentation from Black Hat USA 2021, a pair of researchers show how they found three separate ways to hop between accounts on AWS. Even though fixes for those vulnerabilities were released quickly, the holes reveal that cloud services do not offer the level of isolation expected. The long-term solution may mean changing how the cybersecurity sector handles CVEs.

For the first two isolation breaches, Wiz.io CTO Ami Luttwak and head of research Shir Tamari altered the path prefixes on AWS CloudTrail and Config to allow a user to write to another user's S3 bucket. The third method used the AWS command line to download files from another user's account via the serverless repository.

Sending the logs from several S3 buckets to one is intended for the convenience of an admin who runs several instances, Luttwak and Tamari said in their presentation, "Breaking the Isolation: Cross-Account AWS Vulnerabilities."

"I learned from this behavior that CloudTrail can write to resources that are owned and managed in other accounts," Tamari added. "And for me, a security researcher, there is a concern."

**Customers Notified, So What Happened?**

While Amazon did not have the power to fix the configurations for customers itself — because the fixes involved setting the source account you want, which only the user can decide — it contacted all affected customers to explain the potential problem and how to fix it. Yet when Wiz.io went back after five months, it found that 90% of accounts had not applied the fixes.

Luttwak pointed out that the security team AWS messaged often didn't get the warnings because of the sheer number of accounts they run.

"How do you know this is an important fix to do?" he asked. "And the more we thought about it, the more we understood, this is a big, big problem."

Right now, the system of CVEs allows organizations to check on the latest vulnerabilities, complete with a numerical system of classifying severity and links to vendors' fixes. That works pretty well in most areas of IT. However, cloud vulnerabilities may not get assigned CVE numbers.

"This is because cloud services, as we currently understand them, are not customer controlled," wrote Cloud Security Alliance IT director Kurt Seifried and research analyst Victor Chin. "As a result, vulnerabilities in cloud services are generally not assigned CVE IDs."

**The Amazon Exception**

CVEs take pains to point out that cloud services vulns can indeed receive a CVE ID, as long as the owner of the software is the CVE numbering authority (CNA) reporting them. Rule 7.4.4 says the CNA "may" assign a CVE number if it owns the product or service, even if it is not customer controlled and the fix requires customers to take action.

But here's the sticky wicket: Rule 7.4.5 states, "CNAs MUST NOT assign a CVE ID to a vulnerability if the affected product(s) or service(s) are not owned by the CNA, and are not customer controlled."

In short, the real reason why these AWS vulnerabilities were not issued CVEs is that Amazon is not a CNA partner. Microsoft can issue CVEs for its own products and services, as can Google. Whether the appropriate fix is changing the rules to allow any CNA to assign IDs to vulns whose fixes are out of customers' hands or to sign up Amazon as a CNA depends on your perspective. In June 2022, Wiz.io took matters into its own hands by establishing a community database of cloud vulnerabilities to fill the gap.

As Luttwak said, "There's hundreds of services in AWS, and many of them are getting more and more cross account capabilities, because cross account is the main strategy today for organizations using AWS. So the attack surface is just growing."

Why Some Cloud Services Vulnerabilities Are So Hard to Fix

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

Pigeons are way smarter than most people realize, but who knew they were handy with a smartphone? Now it's time to have some fun: Come up with a witty cybersecurity-related caption for the cartoon, above. Our favorite will win a $25 Amazon gift card.

The contest ends on March 1, 2023. Here are four convenient ways to submit your ideas:

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

**Last Month's Winner**

Congratulations to recently retired advertising creative director Jeff Sawyer, who these days says he claims the title of VP/Lethargy and, now, Edge contest winner. Jeff's caption (below) for January's "Upside Down World" amused us all.

    

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: For the Birds

OpenSearch Anomaly Detection identifies atypical data and receives automatic notifications. There is an issue with the application of document and field level restrictions in the Anomaly Detection plugin, where users with the Anomaly Detector role can read aggregated numerical data (e.g. averages, sums) of fields that are otherwise restricted to them. This issue only affects authenticated users who were previously granted read access to the indexes containing the restricted fields. This issue has been patched in versions 1.3.8 and 2.6.0. There are no known workarounds for this issue.

**Affected versions**

OpenSearch 1.0.0-1.3.7 and 2.0.0-2.5.0

**Patched versions**

OpenSearch 1.3.8 and 2.6.0

**Impact**

There is an issue with the application of document and field level restrictions in the Anomaly Detection plugin, where users with the Anomaly Detector role can read aggregated numerical data (e.g. averages, sums) of fields that are otherwise restricted to them.

This issue only affects authenticated users who were previously granted read access to the indexes containing the restricted fields.

**Workarounds**

There are no known workarounds for this issue.

**Patches**

OpenSearch versions 1.3.8 and 2.6.0 contain a fix for this issue.

**For more information**

If you have any questions or comments about this advisory we ask that contact AWS/Amazon Security via our vulnerability reporting page or directly via email to aws-security@amazon.com. Please do not create a public GitHub issue.

CVE-2023-23933: Issue in Anomaly Detection with document and field level rules in numerical feature aggregations

The greatly expanding attack surface created by the cloud needs to be protected.

The challenges facing chief information security officers (CISOs) have evolved dramatically in the past decade. Today, they must align their security efforts — and budgets — with the business goals of their organization, which may range from maintaining customer confidence that their data is safe to protecting intellectual property from theft.

As a key member of the executive management team, CISOs often have board-level reporting responsibilities. They must manage a new and daunting level of technical complexity introduced by the cloud, where identities are virtually the first and last line of defense. And the job doesn't end there. To be successful, they must also put substantial effort into building a team with skills in a variety of disciplines, and choosing the right defensive technologies.

**The Technical Challenge**

The transition to remote or hybrid work models combined with accelerated cloud adoption has greatly expanded the attack surface CISOs must protect. Furthermore, they often have to deal with more than one cloud. The major providers — Amazon Web Services, Azure, and Google Cloud Platform — all have slightly different structures, procedures, requirements, and so on, all of which further increase the complexity of managing these sprawling architectures.

Data-center-oriented companies that have transitioned to the cloud obviously face a new set of security concerns that conventional firewalls were never designed to handle. Hence, the now commonly heard refrain "Identity is the new perimeter." This is certainly true. While firewalls and other network-based controls shouldn't be abandoned, CISOs need to focus on identity issues. The following three-step process can deliver results in this area quickly and efficiently.

*   **Rein in excess privileges****.** During a migration to the cloud, global privileges are often granted to everyone on the transition team. It's best to avoid this, but if it happens, privileges should be reviewed and limited after the transition. One good way to do this is to monitor which resources are being accessed by which individuals. If an individual isn't accessing a particular resource, the right to do so should be revoked.
*   **Correlate excess privileges and misconfigurations****.** Cloud misconfigurations are another serious risk. But when a privileged identity has access to a misconfigured cloud resource, the results can be disastrous. Fortunately, automated tools are now available to help detect misconfigurations, as well as excessive privileges, and remediate them to eliminate threats.
    
*   **Prioritize****.** There is never enough time or enough staff to correct every misconfiguration, so it's important to focus on those that are the greatest source of security risk. For example, remediating identity-based access threats to cloud storage buckets is critical for preventing data breaches. Monitoring for configuration errors that expose data through excessive, default, etc., permissions should be a top priority.

**The Human Challenge**

Securing cloud infrastructure demands unique skills, and finding qualified individuals to do the work is one of CISOs' biggest challenges. There are three key areas of competency that every cloud security team should possess:

*   **Architectural competence.** To assess an organization's security posture and create a road map for maturing it over time, security teams require a reference model. The CSA framework is an excellent resource, and there are several others available. Without a clear understanding of architectural concepts presented in industry standard security frameworks like CSA, it's difficult to reduce the cloud attack surface and easy to overlook blind spots.
*   **Cloud engineering.** The security team also needs to handle the day-to-day requirements of cloud security, which may include management, maintenance, and more. Competent cloud engineering is essential for "keeping the lights on" in the security sphere.
    
*   **Reactive capabilities.** Globally, cyberattacks occur at the rate of 30,000 per day. Every enterprise can expect incidents to occur on a regular basis, and security teams need specialists who can react quickly to limit — if not prevent — serious consequences.
    

The ideal makeup of a cloud security team spans network, cloud, and development specialists who can work collaboratively. The task of building a team with these capabilities is complicated by the fact that there is a shortage of 3.4 million cybersecurity workers at the moment.

One approach that works well as a supplement to hiring is development from within through training. This may occur in-house or through third-party certification programs. Also, in choosing vendors, organizations should favor those whose offerings include a strong training component. If possible, CISOs may find ways to get non-security employees to work on some security tasks.

Once assembled, one of the problems that any security team will encounter is dealing with multi-cloud architectures, which are becoming the norm. Very few individuals are familiar with the tools, nomenclature, and security model of all three major cloud platforms. For this reason, many companies are turning to cloud native technologies that understand the nuances associated with securing different cloud platforms and simplify security tasks for users that may lack specialized training in AWS, Azure, GCP, etc.

To sum up, the challenges facing today's CISOs are largely driven by the cloud, which creates a greatly expanded attack surface that needs to be protected. Meanwhile, mastering the management model and tools used by each cloud platform requires security expertise that is in extremely short supply. Solutions are available that provide the visibility and platform knowledge needed to help security teams implement best practices for protecting their cloud infrastructure, while helping them up-skill analysts in the process.

How the Cloud Is Shifting CISO Priorities

By Owais Sultan
What is a CDN? How can businesses benefit from a CDN? and What to look for in a CDN provider?
This is a post from HackRead.com Read the original post: Content Delivery Network (CDN) FAQs

Content Delivery Networks (CDNs) have become increasingly popular among businesses of all sizes in recent years. They offer a host of benefits to businesses, which can help to aid the smooth running of operations and boost reputation, efficiency, reliability, security, and the business’s bottom line. This is why they have gained such popularity among businesses in a wide variety of industries.

If you are considering investing in CDN services, you need to ensure you choose the right solution and provider for your business’s needs. Additionally, you should do thorough research to learn how these solutions can help your business.

You can learn about everything from the convenience of integrated CDN solutions to how CDN can help your business when you conduct research. Looking at FAQs about CDN services and solutions can also help; we have provided a sample of common questions and answers below.

**Some Common Questions**

If you want to get to grips with CDN solutions and how they could help your business, here are a few of the many common questions and answers:

**What Is a Content Delivery Network?**

A CDN is a collection of servers that are geographically distributed and work in tandem to ensure the speedy, efficient, and reliable delivery of internet content. It enables the swift transfer of assets required for loading Internet content, including javascript files, HTML pages, videos, images, and more.

The popularity of CDNs means that most web traffic is served through them, including for high-traffic sites such as Facebook and Amazon.

**Does a CDN Replace Web Hosting?**

Another common question is whether a CDN replaces web hosting; the answer is no. CDNs do not host content, but they do help to cache content to improve performance. Standard hosting services often do little to boost performance; this is where a CDN can help. By reducing hosting bandwidth through caching, the CDN can help improve performance, reduce interruptions, boost security, and even cut costs.

**How Can Businesses Benefit from a CDN?**

Following the previous question and answer, there are many ways in which businesses can benefit from CDNs, boosting their popularity. You will find that this is a cost-effective solution; it can reduce downtime, boost performance, provide greater security, and help to speed things up, among other things.

**What Do You Look for in a CDN Provider?**

Many people are eager to know what they should look for in a CDN service provider, and there are several key factors to keep in mind. Of course, the cost of the solution is an important factor to help keep your business within budget.

However, you also need to look at things such as DNS response times, network connectivity, throughput and wait times, and cache hit-or-miss ratios, among other things.

**Conclusion**

In conclusion, Content Delivery Networks are a powerful tool for businesses that need to improve their website’s performance, scalability and security. With the help of this FAQ, we hope that readers have been able to better understand the basics of CDNs and can now decide whether they should consider using one for their website.

As with any technology, there are both advantages and disadvantages that must be considered before investing in a Content Delivery Network.

1.  Cloud Hacking – Why API Remains the Biggest Threat?
2.  VPS Hosting Vs. Dedicated Servers – Which Is Better?
3.  Managed Cloud Hosting vs. Unmanaged Cloud Hosting
4.  5 WordPress Security Solutions with Free SSL Certificates
5.  How Web Application Firewall (WAF) protects your website

Owais takes care of Hackread's social media from the very first day. At the same time He is pursuing for chartered accountancy and doing part time freelance writing.

Content Delivery Network (CDN) FAQs

The average organization does business with 11 third parties, and 98% of organizations do business with a third party who has suffered a breach, an analysis finds.

Nearly every company does business with — or uses the products of — a third party that has suffered a compromise, thus increasing their security risks.

That's according to data science firm Cyentia Institute, which has issued an analysis that includes external measurements of security from more than 230,000 organizations provided by cybersecurity risk-management firm SecurityScorecard. It found that the average firm had around 10 third-party relationships, and hundreds of indirect fourth-party relationships, with the typical firm having 60 to 90 times more fourth parties than third parties. Nearly all firms (98%) had at least one third-party partner who had suffered a breach, the report stated.

The IT sector has the most third parties, with an average of 25, while the finance sector had the fewest, at 6.5. Those numbers quickly balloon when fourth-party relationships are included, as did their risk. The average firm has an indirect relationship with 200 fourth parties that have had a breach, the analysis found.

The research underscores the sprawling nature of third- and fourth-party relationships for corporations, and the dramatic increase in risk that they can cause, says Wade Baker, founder and partner at the Cyentia Institute.

"Risk goes downhill," he says. "The first parties are more likely to have good security \[risk\] scores than their third parties, and with fourth parties, the numbers really explode. You need to expect \[these firms and products\] to not be up to your standards for security."

That's because while many organizations have become more mature regarding their own cyber risks, few are cognizant of the extended risks, Cyentia and SecurityScorecard stated in the analysis.

"Many organizations are still unaware of the dependencies and exposures inherent to third-party relationships, and simply focus on managing their own security posture," the report stated. "Others are aware of those issues, but don't make vendor decisions based on security and/or require vendors to meet certain standards. Even firms that do establish third-party security requirements can struggle to continually monitor compliance and progress."

    

Almost all companies did business with a third party who had been compromised in the past 2 years. Source: Cyentia Institute and SecurityScorecard

Third-party and supply-chain risk have become significant issues in recent years. And CISOs have become increasing wary of their third-party providers, ever since the compromise of an HVAC supplier led to the breach of retail giant Target.

While the analysis looks at third-party risk, the definition of what a third party is extends not just to vendors and partners, but software providers and open source projects. Now-infamous attacks on software suppliers such as SolarWinds, and vulnerabilities in widely used software components such as Log4J, have raised the visibility of the risk that this arena poses.

The top 5 technologies included in third-party relationships within the data are Google Analytics, Google Tag Manager, Amazon Web Hosting, PHP, and Facebook products — all of which were involved in two-thirds (68%) of third-party relationships, the report stated.

"A lot of these third and fourth party relationships \[involve us\] both agreeing to adhere to certain policies just by virtue of using a product, and now I'm opening up myself to a certain degree of risk," Baker says.

**Risk Rises With Each Hop**

The analysis also found that third parties typically have a weaker security posture than the companies they served. Overall, there is a much higher likelihood that third parties will have security problems, meaning that companies can't assume that all of their third parties are as diligent about security.

"I view it in the same way as all of us knowing we have too many privileges — in general, people have access to more data than they need to do their job," Baker says. "It would be good to reduce the number of third parties, especially if they're not needed, and also be a little bit more choosy."

The data, however, does not suggest a clear path forward, beside becoming more aware of the problem. Baker does not necessarily recommend, for example, that organizations cut the bottom 25% of their third parties from their business. However, evaluating them more closely or more frequently might be more realistic, he says.

"If we really want to protect our supply chains, we've got to we've got to make the weakest link stronger," Baker says. "And I think the analysis is showing that there's a lot of weak links across third parties and fourth parties, and that is where the challenge lies."

Nearly All Firms Have Ties With Breached Third Parties

Cross site scripting (XSS) vulnerability in Zoho ManageEngine ServiceDesk Plus 14 via embedding videos in the language component.

Zoho offers this Vulnerability Reward Program (VRP) to continuously improve the security of our products. If you believe you have discovered a potential security vulnerability in any of Zoho's products or assets, let us know immediately, and we will make every effort to get the issues addressed as quickly as possible.

Please ensure you understand the program rules before you report a vulnerability. By participating in this program, you agree to be bound by these rules. Zoho provides monetary rewards to vulnerability reporters at its discretion and the reward may vary based upon metrics including (but not limited to) vulnerability severity, impact, and exploitability.

You can share details of the suspected vulnerability with Zoho by clicking below;

Submit Bug

These Bug Bounty Terms and Conditions ("Bug Bounty Terms") govern your participation in the Zoho Bug Bounty Program ("Bug Bounty Program") and are a legally binding contract between you or the company you represent and Zoho. By submitting a vulnerability or participating in the program, you agree to be bound by the Terms.

The Bug Bounty Program enables you to submit security bugs or vulnerabilities discovered by you in eligible Zoho Services and earn rewards for your submissions. Service-specific terms of use that are applicable to specific Zoho Services ("Service-Specific Terms") shall be applicable to you in addition to the Bug Bounty Terms. In the event of a conflict between Bug Bounty Terms and Service-specific Terms, the Bug Bounty Terms shall prevail.

Participation in the Bug Bounty Program is open to all individuals unless:

*   You are below 14 years of age. If you are 14 years old or above, but you are considered a minor in your place of residence, you must obtain your parent's or legal guardian's permission prior to your participation in the Bug Bounty Program after having read the Bug Bounty Terms;
    
*   You are a resident of any US sanctioned countries;
    
*   You are currently an employee of Zoho or you were employed by Zoho within six (6) months prior to your participation in the Bug Bounty Program; or
    
*   You are a family member of a Zoho employee.
    

You will follow the rules specified hereunder, failing which your participation in the Bug Bounty Program will be immediately terminated.

*   You will make all efforts to avoid privacy violations, degradation of user experience, degradation of Zoho Services, disruptions to Zoho's infrastructure and systems, and destruction of both Zoho's and users' data in the course of your security bug research.
    
*   You will report any security bug discovered by you ("Security Bug") to Zoho and provide Zoho with reasonable time to identify and mitigate the security bug before publicly disclosing it to others.
    
*   During your security bug research, if you have any inadvertent access to Zoho's or users' information, including sensitive, personal, or any other unauthorized information ("Unauthorized Information"), you must cease your Security Bug research to prevent further access to any Unauthorized Information by you and notify Zoho of any Unauthorized Information you accessed. Upon notifying Zoho of such access, delete all Unauthorized Information from your systems or devices.
    
*   You will always use your account, or an account for which you have explicit consent from the account owner, for testing the Security Bug.
    
*   You will use any security bug discovered by you only for testing, and you will not exploit the Security Bug in any manner.
    

If you have discovered an eligible security bug as specified in the scope, you may submit the bug through the website provided to you for submission.

Your submission shall include details such as vulnerability description, clear reproduction steps, and a proof-of-concept.

Upon receipt of your submission, Zoho will review and validate the submission within three (3) days from the date of your submission and will prioritize based on the severity of the vulnerability submitted and resolve the vulnerability accordingly. Zoho will notify you once the vulnerability is resolved and you may confirm whether the remedy resolves the vulnerability. If there is more than one submission for the same vulnerability from different parties, bounty will be paid to the first submission.

Zoho will pay a reward for your eligible submissions ("Bounty"). Bounties will be determined and granted only at Zoho's discretion. You can find the reward tiers here.

Zoho will fulfill the Bounty payments through the following payment modes:

*   For Indian participants, in INR through wire transfer;
    
*   For participants from outside India, in USD through PayPal; or
    
*   As an Amazon gift card in USD.
    

You understand that you are responsible for paying the taxes associated with Bounty payments. Bounties for Indian participants will be paid only after deducting TDS of 10% (Tax Deducted at Source).

Bounties shall be claimed by you within a period of three (3) months from the date of your entitlement to the reward.

You grant Zoho non-exclusive, irrevocable, worldwide, perpetual, and royalty-free license to review, assess, and use your submission to analyze and resolve the vulnerability submitted by you and for other related purposes.

ZOHO SHALL IN NO EVENT BE LIABLE FOR ANY CONSEQUENTIAL, INCIDENTAL, INDIRECT, SPECIAL, PUNITIVE, OR OTHER LOSS OR DAMAGE WHATSOEVER OR FOR LOSS OF BUSINESS PROFITS, BUSINESS INTERRUPTION, COMPUTER FAILURE, LOSS OF BUSINESS INFORMATION, OR OTHER LOSS ARISING OUT OF THE BUG BOUNTY PROGRAM.

*   All Zoho branded products and applications listed at zoho.com
    
*   All ManageEngine branded products and applications listed at manageengine.com (except SupportCenter Plus)
    
*   Site24x7
    
*   Qntrl
    
*   TrainerCentral
    
*   Zoho Corporation owned assets
    

*   Missing any best security practice that is not a vulnerability
    
*   Self XSS
    
*   Username or email address enumeration
    
*   Email bombing
    
*   HTML injection
    
*   XSS vulnerabilities on sandbox or user-content domains
    
*   Unvalidated or open redirects or tabnabbing
    
*   Clickjacking in unauthenticated pages or in pages with no significant state-changing action
    
*   Logout or unauthenticated CSRF
    
*   Missing cookie flags on non-sensitive cookies
    
*   Missing security headers that do not lead directly to a vulnerability
    
*   Unvalidated findings from automated tools or scans
    
*   "Back" button that keeps working after logout
    
*   Issues that do not affect the latest version of modern browsers or platforms
    
*   Attacks that require physical access to a user device
    
*   Social engineering
    
*   Hosting malware/arbitrary content on Zoho and causing downloads
    
*   Use of a known-vulnerable library (without evidence of exploitability)
    
*   Low-impact descriptive error pages and information disclosures without any sensitive information
    
*   Invalid or missing SPF/DKIM/DMARC/BIMI records
    
*   Password and account policies, such as (but not limited to) reset link expiration or password complexity
    
*   Non-critical issues in blog.zoho.com or other product blogs
    
*   CSV injection
    
*   Phishing risk via Unicode/Punycode or RTLO issues
    
*   Missing rate limitations on endpoints (without any security concerns)
    
*   Presence of EXIF information in file uploads
    
*   Ability to upload/download executables
    
*   Bypassing pricing/paid feature restrictions
    
*   0-day vulnerabilities in any third parties we use within 10 days of their disclosure
    
*   Any other issues determined to be of low or negligible security impact
    
*   Issues that do not affect the latest version of applications, modern browsers, or platforms
    
*   Vulnerabilities that resulted from implementation that does not follow our deployment guidelines
    
*   Usage of known vulnerable components without actual working exploit
    
*   Our intended features or accepted risks (including but not limited to the following) are not vulnerabilities and are thus excluded from our program:
    
*   Applications running as SYSTEM user
    
*   Features to execute queries, scripts, or workflows by privileged users
    
*   Usage of UDP-based unauthenticated protocols (which can be disabled by the user)
    

Severity

Bounty in USD (Up to)

Low

$ 50

Medium

$ 200

High

$ 800

Critical

$ 3000

We would like to truly thank the people listed in the Hall of Fame for their participation in the program and for making a responsible disclosure of the vulnerabilities.

Hall Of Fame for

CVE-2023-23074: BugBounty

Cross site scripting (XSS) vulnerability in Zoho ManageEngine ServiceDesk Plus 14 via PO in the purchase component.

Tag

#amazon