Hackers are actively exploiting a pair of recently discovered vulnerabilities to remotely commandeer network-attached storage devices manufactured by D-Link, researchers said Monday.

Roughly 92,000 devices are vulnerable to the remote takeover exploits, which can be remotely transmitted by sending malicious commands through simple HTTP traffic. The vulnerability came to light two weeks ago. The researcher said they were making the threat public because D-Link said it had no plans to patch the vulnerabilities, which are present only in end-of-life devices, meaning they are no longer supported by the manufacturer.

An ideal recipe

On Monday, researchers said their sensors began detecting active attempts to exploit the vulnerabilities starting over the weekend. Greynoise, one of the organizations reporting the in-the-wild exploitation, said in an email that the activity began around 02:17 UTC on Sunday. The attacks attempted to download and install one of several pieces of malware on vulnerable devices depending on their specific hardware profile. One such piece of malware is flagged under various names by 40 endpoint protection services.

Security organization Shadowserver has also reported seeing scanning or exploits from multiple IP addresses but didn’t provide additional details.

The vulnerability pair, found in the nas_sharing.cgi programming interface of the vulnerable devices, provide an ideal recipe for remote takeover. The first, tracked as CVE-2024-3272 and carrying a severity rating of 9.8 out of 10, is a backdoor account enabled by credentials hardcoded into the firmware. The second is a command-injection flaw tracked as CVE-2024-3273 and has a severity rating of 7.3. It can be remotely activated with a simple HTTP GET request.

Netsecfish, the researcher who disclosed the vulnerabilities, demonstrated how a hacker could remotely commandeer vulnerable devices by sending a simple set of HTTP requests to them. The code looks like this:

GET /cgi-bin/nas_sharing.cgiuser=messagebus&passwd=&cmd=15&system=<BASE64_ENCODED_COMMAND_TO_BE_EXECUTED>

In the exploit example below, the text inside the first red rectangle contains the hardcoded credentials—username messagebus and an empty password field—while the next rectangle contains a malicious command string that has been base64 encoded.

“Successful exploitation of this vulnerability could allow an attacker to execute arbitrary commands on the system, potentially leading to unauthorized access to sensitive information, modification of system configurations, or denial of service conditions,” netsecfish wrote.

Last week, D-Link published an advisory. D-Link confirmed the list of affected devices:

According to netsecfish, Internet scans found roughly 92,000 devices that were vulnerable.

According to the Greynoise email, exploits company researchers are seeing look like this:

GET /cgi-bin/nas_sharing.cgi?dbg=1&cmd=15&user=messagebus&passwd=&cmd=Y2QgL3RtcDsgcLnNo HTTP/1.1

Other malware invoked in the exploit attempts include:

The best defense against these attacks and others like them is to replace hardware once it reaches end of life. Barring that, users of EoL devices should at least ensure they’re running the most recent firmware. D-Link provides this dedicated support page for legacy devices for owners to locate the latest available firmware. Another effective protection is to disable UPnP and connections from remote Internet addresses unless they’re absolutely necessary and configured correctly.

https://arstechnica.com/?p=2015480

VMware is urging customers to patch critical vulnerabilities that make it possible for hackers to break out of sandbox and hypervisor protections in all versions, including out-of-support ones, of VMware ESXi, Workstation, Fusion, and Cloud Foundation products.

A constellation of four vulnerabilities—two carrying severity ratings of 9.3 out of a possible 10—are serious because they undermine the fundamental purpose of the VMware products, which is to run sensitive operations inside a virtual machine that’s segmented from the host machine. VMware officials said that the prospect of a hypervisor escape warranted an immediate response under the company’s IT Infrastructure Library, a process usually abbreviated as ITIL.

“Emergency change”

“In ITIL terms, this situation qualifies as an emergency change, necessitating prompt action from your organization,” the officials wrote in a post. “However, the appropriate security response varies depending on specific circumstances.”

Among the specific circumstances, one concerns which vulnerable product a customer is using, and another is whether and how it may be positioned behind a firewall. A VMware advisory included the following matrix showing how the vulnerabilities—tracked as CVE-2024-22252, CVE-2024-22253, CVE-2024-22254, CVE-2024-22255—affect each of the vulnerable products:

Three of the vulnerabilities affect the USB controller the products use to support peripheral devices such as keyboards and mice. The advisory describes the vulnerabilities as:

CVE-2024-22252: a use-after-free vulnerability in XHCI USB controller with a maximum severity range of 9.3 for Workstation/Fusion and a base score of 8.4 for ESXi. Someone with local administrative privileges on a virtual machine can execute code as the virtual machine’s VMX process running on the host. On ESXi, the exploitation is contained within the VMX sandbox, whereas, on Workstation and Fusion, this could lead to code execution on the machine where Workstation or Fusion is installed.

CVE-2024-22253: a use-after-free vulnerability in UHCI USB controller with a maximum severity rating of 9.3 for Workstation/Fusion and a base score of 8.4 for ESXi. Exploitation requirements and outcomes are the same as for CVE-2024-22252.

CVE-2024-22254: an out-of-bounds write vulnerability with a maximum severity base score of 7.9. This vulnerability makes it possible for someone with privileges within the VMX process to trigger an out-of-bounds write leading to a sandbox escape.

CVE-2024-22255: an information disclosure vulnerability in the UHCI USB controller with a maximum CVSSv3 base score of 7.1. Someone with administrative access to a virtual machine can exploit it to leak memory from the vmx process.

Broadcom, the VMware parent company, is urging customers to patch vulnerable products. As a workaround, users can remove USB controllers from vulnerable virtual machines, but Broadcom stressed that this measure could degrade virtual console functionality and should be viewed as only a temporary solution. In an article explaining how to remove a USB controller, officials wrote:

The workaround is to remove all USB controllers from the Virtual Machine. As a result, USB passthrough functionality will be unavailable.

In addition, virtual/emulated USB devices, such as VMware virtual USB stick or dongle, will not be available for use by the virtual machine. In contrast, the default keyboard/mouse as input devices are not affected as they are, by default, not connected through USB protocol but have a driver that does software device emulation in the guest OS.

IMPORTANT:
Certain guest operating systems, including Mac OS, do not support using a PS/2 mouse and keyboard. These guest operating systems will be left without a mouse and keyboard without a USB controller.

VMware said it isn’t aware of any evidence that any of the vulnerabilities are under active exploitation.

https://arstechnica.com/?p=2008406

Linux developers are in the process of patching a high-severity vulnerability that, in certain cases, allows the installation of malware that runs at the firmware level, giving infections access to the deepest parts of a device where they’re hard to detect or remove.

The vulnerability resides in shim, which in the context of Linux is a small component that runs in the firmware early in the boot process before the operating system has started. More specifically, the shim accompanying virtually all Linux distributions plays a crucial role in secure boot, a protection built into most modern computing devices to ensure every link in the boot process comes from a verified, trusted supplier. Successful exploitation of the vulnerability allows attackers to neutralize this mechanism by executing malicious firmware at the earliest stages of the boot process before the Unified Extensible Firmware Interface firmware has loaded and handed off control to the operating system.

The vulnerability, tracked as CVE-2023-40547, is what’s known as a buffer overflow, a coding bug that allows attackers to execute code of their choice. It resides in a part of the shim that processes booting up from a central server on a network using the same HTTP that the Internet is based on. Attackers can exploit the code-execution vulnerability in various scenarios, virtually all following some form of successful compromise of either the targeted device or the server or network the device boots from.

“An attacker would need to be able to coerce a system into booting from HTTP if it’s not already doing so, and either be in a position to run the HTTP server in question or MITM traffic to it,” Matthew Garrett, a security developer and one of the original shim authors, wrote in an online interview. “An attacker (physically present or who has already compromised root on the system) could use this to subvert secure boot (add a new boot entry to a server they control, compromise shim, execute arbitrary code).”

Stated differently, these scenarios include:

• Acquiring the ability to compromise a server or perform an adversary-in-the-middle impersonation of it to target a device that’s already configured to boot using HTTP
• Already having physical access to a device or gaining administrative control by exploiting a separate vulnerability.

While these hurdles are steep, they’re by no means impossible, particularly the ability to compromise or impersonate a server that communicates with devices over HTTP, which is unencrypted and requires no authentication. These particular scenarios could prove useful if an attacker has already gained some level of access inside a network and is looking to take control of connected end-user devices. These scenarios, however, are largely remedied if servers use HTTPS, the variant of HTTP that requires a server to authenticate itself. In that case, the attacker would first have to forge the digital certificate the server uses to prove it’s authorized to provide boot firmware to devices.

The ability to gain physical access to a device is also difficult and is widely regarded as grounds for considering it to be already compromised. And, of course, already obtaining administrative control through exploiting a separate vulnerability in the operating system is hard and allows attackers to achieve all kinds of malicious objectives.

https://arstechnica.com/?p=2001542

Mass exploitation began over the weekend for yet another critical vulnerability in widely used VPN software sold by Ivanti, as hackers already targeting two previous vulnerabilities diversified, researchers said Monday.

The new vulnerability, tracked as CVE-2024-21893, is what’s known as a server-side request forgery. Ivanti disclosed it on January 22, along with a separate vulnerability that so far has shown no signs of being exploited. Last Wednesday, nine days later, Ivanti said CVE-2024-21893 was under active exploitation, aggravating an already chaotic few weeks. All of the vulnerabilities affect Ivanti’s Connect Secure and Policy Secure VPN products.

A tarnished reputation and battered security professionals

The new vulnerability came to light as two other vulnerabilities were already under mass exploitation, mostly by a hacking group researchers have said is backed by the Chinese government. Ivanti provided mitigation guidance for the two vulnerabilities on January 11 and released a proper patch last week. The Cybersecurity and Infrastructure Security Agency, meanwhile, mandated all federal agencies under its authority disconnect Ivanti VPN products from the Internet until they are rebuilt from scratch and running the latest software version.

By Sunday, attacks targeting CVE-2024-21893 had mushroomed, from hitting what Ivanti said was a “small number of customers” to a mass base of users, research from security organization Shadowserver showed. The steep line in the right-most part of the following graph tracks the vulnerability’s meteoric rise starting on Friday. At the time this Ars post went live, the exploitation volume of the vulnerability exceeded that of CVE-2023-46805 and CVE-2024-21887, the previous Ivanti vulnerabilities under active targeting.

Systems that had been inoculated against the two older vulnerabilities by following Ivanti’s mitigation process remained wide open to the newest vulnerability, a status that likely made it attractive to hackers. There’s something else that makes CVE-2024-21893 attractive to threat actors: because it resides in Ivanti’s implementation of the open source Security Assertion Markup Language—which handles authentication and authorization between parties—people who exploit the bug can bypass normal authentication measures and gain access directly to the administrative controls of the underlying server.

Exploitation likely got a boost from proof-of-concept code released by security firm Rapid7 on Friday, but the exploit wasn’t the sole contributor. Shadowserver said it began seeing working exploits a few hours before the Rapid7 release. All of the different exploits work roughly the same way. Authentication in Ivanti VPNs occurs through the doAuthCheck function in an HTTP web server binary located at /root/home/bin/web. The endpoint /dana-ws/saml20.ws doesn’t require authentication. As this Ars post was going live, Shadowserver counted a little more than 22,000 instances of Connect Secure and Policy Secure.

VPNs are an ideal target for hackers seeking access deep inside a network. The devices, which allow employees to log in to work portals using an encrypted connection, sit at the very edge of the network, where they respond to requests from any device that knows the correct port configuration. Once attackers establish a beachhead on a VPN, they can often pivot to more sensitive parts of a network.

The three-week spree of non-stop exploitation has tarnished Ivanti’s reputation for security and battered security professionals as they have scrambled—often in vain—to stanch the flow of compromises. Compounding the problem was a slow patch time that missed Ivanti’s own January 24 deadline by a week. Making matters worse still: hackers figured out how to bypass the mitigation advice Ivanti provided for the first pair of vulnerabilities.

Given the false starts and high stakes, CISA’s Friday mandate of rebuilding all servers from scratch once they have installed the latest patch is prudent. The requirement doesn’t apply to non-government agencies, but given the chaos and difficulty securing the Ivanti VPNs in recent weeks, it’s a common-sense move that all users should have taken by now.

https://arstechnica.com/?p=2001230

UEFI firmware from five of the leading suppliers contains vulnerabilities that allow attackers with a toehold in a user’s network to infect connected devices with malware that runs at the firmware level.

The vulnerabilities, which collectively have been dubbed PixieFail by the researchers who discovered them, pose a threat mostly to public and private data centers, and their users of course. People with even minimal access to such a network—say a paying customer, a low-level employee, or an attacker who has already gained limited entry—can exploit the vulnerabilities to infect connected devices with a malicious UEFI. Short for Unified Extensible Firmware Interface, UEFI is the low-level and complex chain of firmware responsible for booting up virtually every modern computer. By installing malicious firmware that runs prior to the loading of a main OS, UEFI infections can’t be detected or removed using standard endpoint protections. They also give unusually broad control of the infected device.

Five vendors, and many a customer, affected

The nine vulnerabilities that comprise PixieFail reside in TianoCore EDK II, an open source implementation of the UEFI specification. The implementation is incorporated into offerings from Arm Ltd., Insyde, AMI, Phoenix Technologies, and Microsoft. The flaws reside in functions related to IPv6, the successor to the IPv4 Internet Protocol network address system. They can be exploited in what’s known as the PXE, or Preboot Execution Environment, when it’s configured to use IPv6.

PXE, sometimes colloquially referred to as Pixieboot or netboot, is a mechanism enterprises use to boot up large numbers of devices, which more often than not are servers inside of large data centers. Rather than the OS being stored on the device booting up, PXE stores the image on a central server, known as a boot server. Devices booting up locate the boot server using the Dynamic Host Configuration Protocol and then send a request for the OS image.

PXE is designed for ease of use, uniformity, and quality assurance inside data centers and cloud environments. When updating or reconfiguring the OS, admins need to do so only once and then ensure that hundreds or thousands of connected servers run it each time they boot up.

By exploiting the PixieFail vulnerabilities, an attacker can cause servers to download a malicious firmware image rather than the intended one. The malicious image in this scenario will establish a permanent beachhead on the device that’s installed prior to the loading of the OS and any security software that would normally flag infections.

The vulnerabilities and proof-of-concept code demonstrating the presence of the vulnerabilities were developed by researchers from security firm Quarkslab, which published the findings Tuesday.

The network presence required to exploit most of the vulnerabilities is relatively minor. Attackers need not establish their own malicious server or gain high-level privileges. Instead, the attacker only needs the ability to view and capture traffic as it traverses the local network. This kind of access may be possible when someone has a legitimate account with a cloud service or after first exploiting a separate vulnerability that gives limited system rights. With that, the attacker can then exploit PixieFail to plant a UEFI-controlled backdoor in huge fleets of servers.

Quarkslab Chief Research Officer Iván Arce said in an interview:

An attacker doesn’t need to have physical access neither to the client nor the boot server. The attacker just needs to have access to the network where all these systems are running and it needs to have the ability to capture packets and to inject packets or transmit packets. When the client-{based server] boots, the attacker just needs to send the client a malicious packet in the [request] response that will trigger some of these vulns. The only access that the attacker needs is access to the network, not physical access to any of the clients, nor to the boot server or DHCP server. Just capture packets or send packets in the network, where all these servers are running.

For PixieFail to be exploited, PXE must be turned on. For the overwhelming number of UEFIs in use, PXE isn’t turned on. PXE is generally used only in data centers and cloud environments for rebooting thousands or tens of thousands of servers. Additionally, PXE must be configured to be used in combination with IPv6 routing.

https://arstechnica.com/?p=1996543

Threat actors have started exploiting a critical information disclosure vulnerability in the open source file-sharing and collaboration software ownCloud only days after its public disclosure.

The vulnerability, tracked as CVE-2023-49103, impacts the Graphapi app, allowing attackers to retrieve sensitive environment variables, including credentials, license keys, and other system information.

Impacting Graphapi versions 0.2.0 to 0.3.0, the flaw cannot be mitigated by disabling the Graphapi app, and also requires changing passwords for administrative accounts, access keys, and credentials for the mail server and database.

ownCloud disclosed the vulnerability on November 21, along with two other critical issues in the software (CVE-2023-49104 and CVE-2023-49105). On Monday, the US cybersecurity agency CISA included the bugs in its weekly vulnerability roundup, without a severity rating.

Also on Monday, attack activity and exposed asset tracking services issued warnings about the first in-the-wild exploitation attempts targeting CVE-2023-49103.

Nonprofit cybersecurity organization Shadowserver Foundation warned that it has identified roughly 11,000 ownCloud instances that are exposed to the internet, and which are potentially at risk.

The largest number of these instances are in Germany (2,000), followed by the US (1,400), and France (1,300). Russia, Poland, the Netherlands, Italy, the UK, Canada, and Spain round up top 10, with hundreds of instances each.

Shadowserver warns that the vulnerability is very easy to exploit, urging administrators to follow the mitigation steps outlined by ownCloud.

According to data from Greynoise, the targeting of CVE-2023-49103 started on November 25, with attacks originating from a single IP address. The number of exploitation attempts increased on Monday, with 11 unique IPs joining the fray.

Johannes Ullrich of the SANS Internet Storm Center too warned of activity targeting the ownCloud vulnerability, detailing five IPs involved in the observed attacks, which have scanned for files within vulnerable ownCloud instances.

“This pattern can suggest potential coordinated efforts by threat actors or botnets aiming to exploit the disclosed security flaw,” SOC Radar notes.

Ullrich, however, points out that there is a steady flow of attacks targeting ownCloud instances, many of which “are likely just attempting to find instances of ownCloud to exploit old vulnerabilities or attempt weak passwords”.

Related: Mass Exploitation of ‘Citrix Bleed’ Vulnerability Underway

Related: In-the-Wild Exploitation Expected for Critical TeamCity Flaw Allowing Server Takeover

Related: Exploitation of Recent Citrix ShareFile RCE Vulnerability Begins

https://www.securityweek.com/exploitation-of-critical-owncloud-vulnerability-begins/

Open-source file-sharing and collaboration software ownCloud is plagued by critical vulnerabilities that could lead to the exposure of credentials and other sensitive information and to authentication and validation bypass.

The most serious issue, which carries a CVSS score of 10/10, impacts the graphapi app, which uses a third-party library providing a URL that, when accessed, reveals the PHP environment’s configuration details (phpinfo).

“This information includes all the environment variables of the webserver. In containerized deployments, these environment variables may include sensitive data such as the ownCloud admin password, mail server credentials, and license key,” ownCloud warned in an advisory.

Additional sensitive data included in phpinfo may allow an attacker to gather further information about the system and the variable should be concerning for all administrators if ownCloud is not running in a containerized environment.

“It’s important to emphasize that simply disabling the graphapi app does not eliminate the vulnerability,” ownCloud notes. The issue impacts graphapi versions 0.2.0 to 0.3.0.

Administrators are advised to change the ownCloud admin password, the Object-Store/S3 access-key, and credentials for the mail server and database. “Additionally, we disabled the phpinfo function in our docker-containers. We will apply various hardenings in future core releases to mitigate similar vulnerabilities,” ownCloud added.

A second vulnerability, tagged with a CVSS severity score of 9.8/10, is described as an authentication bypass in the WebDAV API, through pre-signed URLs.

“It is possible to access, modify or delete any file without authentication if the username of the victim is known and the victim has no signing-key configured (which is the default),” ownCloud explained.

The bug impacts ownCloud core versions 10.6.0 to 10.13.0 and can be mitigated by denying the use of pre-signed URLs if there is no signing key configured for the file owner.

A third bug (CVSS score of 9/10), impacting the oauth2 app versions prior to 0.6.1, could lead to the bypass of subdomain validation.

“Within the oauth2 app an attacker is able to pass in a specially crafted redirect-URL which bypasses the validation code and thus allows the attacker to redirect callbacks to a TLD controlled by the attacker,” ownCloud said.

Related: Over a Dozen Exploitable Vulnerabilities Found in AI/ML Tools

Related: Microsoft Patches Sensitive Information Disclosure Bug in Azure CLI

Related: SAP Patches Critical Vulnerability in Business One Product

https://www.securityweek.com/critical-owncloud-flaws-lead-to-sensitive-information-disclosure-authentication-bypass/

Microsoft announced on Tuesday that it is willing to pay up to $20,000 for vulnerabilities reported as part of a new bug bounty program for Defender products.

The new Microsoft Defender Bounty Program kicks off with Defender for Endpoint APIs, but the tech giant says other products in the Defender brand will be added in time.

“The Microsoft Defender Bounty Program invites researchers across the globe to identify vulnerabilities in Defender products and services and share them with our team,” the company says.

Participating researchers may earn between $500 and $20,000 for the identified flaws, depending on impact and report quality.

The highest rewards, Microsoft says, may be awarded for critical-severity remote code execution (RCE) bugs. The company is willing to hand out up to $8,000 for critical elevation of privilege and information disclosure issues, and may offer up to $3,000 for spoofing and tampering vulnerabilities.

To qualify for a bug bounty reward, researchers need to report flaws that are within the scope of the program, which have not been previously reported, and which can be reproduced on the latest, fully patched version of the product.

In-scope vulnerabilities include cross-site scripting (XSS), cross-site request forgery (CSRF), server-side request forgery (SSRF), cross-tenant data tampering or access, insecure direct object references and insecure deserialization, injection, server-side code execution, and security misconfiguration issues.

Reports covering components with known vulnerabilities should also include proof-of-concept (PoC) exploit code, the tech giant says.

The reports need to be clear and concise, and should include the information necessary to reproduce the issue.

All reports, Microsoft says, should be submitted through the MSRC Researcher Portal, indicate which high-impact scenario they qualify for, and should describe the attack vector for the bug.

“The Defender Bounty program’s scope is limited to technical vulnerabilities in Defender-related products and services. If you discover customer data while conducting your research, or are unclear if it is safe to proceed, please stop and contact us,” the tech giant notes.

Further details on the Microsoft Defender Bounty Program can be found on the MSRC portal.

Related: Microsoft Paid Out $63 Million Since Launch of First Bug Bounty Program 10 Years Ago

Related: Microsoft Offers Up to $15,000 in New AI Bug Bounty Program

Related: Microsoft Paid Out $13 Million via Bug Bounty Programs for Fourth Consecutive Year

https://www.securityweek.com/microsoft-offers-up-to-20000-for-vulnerabilities-in-defender-products/

Australian and US governmental agencies and Citrix this week issued fresh warnings on the exploitation of a critical NetScaler product vulnerability.

Tracked as CVE-2023-4966 (CVSS score of 9.4) and referred to as CitrixBleed, the unauthenticated bug leads to information disclosure. It impacts Netscaler ADC and Gateway appliances that are configured as a gateway or an AAA server.

Patched in October, the flaw had been exploited as a zero-day since August, and mass exploitation started roughly three weeks ago, around the same time that a proof-of-concept (PoC) exploit and a technical writeup were published.

In late October, the tech giant warned that threat actors were exploiting the issue to perform session hijacking, completely bypassing authentication, including MFA protections.

On Monday, Citrix urged administrators to apply the available patches as soon as possible, citing “a sharp increase in attempts to exploit this vulnerability in unpatched NetScaler ADCs” and reports that the LockBit ransomware gang has started exploiting it.

An alert on LockBit targeting CitrixBleed also came from the US cybersecurity agency CISA, the FBI, the Multi-State Information Sharing and Analysis Center (MS-ISAC), and the Australian Cyber Security Center (ACSC), on Tuesday.

“Historically, LockBit affiliates have conducted attacks against organizations of varying sizes across multiple critical infrastructure sectors—including education, energy, financial services, food and agriculture, government and emergency services, healthcare, manufacturing, and transportation,” the governmental agencies warn.

LockBit, the four agencies say, exploited CitrixBleed to gain initial access to Boeing Distribution Inc., the parts and distribution subsidiary of aeronautical giant Boeing.

Armed with valid cookies obtained by exploiting CVE-2023-4966, the LockBit affiliates then established an authenticated session with the appliance, which allowed them to execute a PowerShell script for malware deployment.

“Through the takeover of legitimate user sessions, malicious actors acquire elevated permissions to harvest credentials, move laterally, and access data and resources,” the agencies note.

In their alert, CISA, FBI, MS-ISAC, and ACSC provide a list of indicators of compromise (IoCs) associated with the LockBit attack on Boeing, recommending hunting for evidence of compromise and urging immediate patching.

Administrators are advised to update to NetScaler ADC and Gateway versions 14.1-8.50, 13.1-49.15, 13.0-92.19, and NetScaler ADC 13.1-FIPS 13.1-37.164, 12.1-FIPS 12.1-55.300, and 12.1-NDcPP 12.1-55.300, which address the vulnerability.

After the upgrade, they should remove any active or persistent sessions, to ensure the flaw is fully mitigated – Citrix has provided detailed information on how this can be done. Because the session cookies persist in memory, threat actors can retrieve them even after the update.

Related: CitrixBleed Vulnerability Exploitation Suspected in Toyota Ransomware Attack

Related: Operations at Major Australian Ports Significantly Disrupted by Cyberattack

Related: Atlassian Issues Second Warning on Potential Exploitation of Critical Confluence Flaw

https://www.securityweek.com/citrix-gov-agencies-issue-fresh-warnings-on-citrixbleed-vulnerability/

Microsoft on Monday announced that it has paid out $63 million in rewards to the security researchers participating in its bug bounty programs.

The tech giant launched its first bug bounty programs in 2013, when it was accepting reports of exploitation techniques in Windows 8.1 and flaws in the preview version of Internet Explorer 11.

Initially, Microsoft was receiving less than 100 reports annually, from the few dozen researchers who were participating. The company was paying a few hundred dollars in rewards annually.

Now, the company is running 17 bug bounty programs covering Azure, Edge, Microsoft 365, Windows, Xbox, and more, with rewards of up to $250,000 offered for high-impact bugs in the Hyper-V hypervisor.

According to Microsoft, thousands of security researchers from 70 countries are now receiving bug bounties. Students, academics, and full-time cybersecurity professionals are also participating in the company’s bug bounty programs.

Of the total $63 million handed out since 2013, $60 million were paid over the past five years, the company says. Starting 2020, Microsoft has been handing out more than $13 million annually to roughly 300 researchers.

“The data from the programs is a critical part of arming product and security teams across the company to deliver broader security improvements and mitigations beyond one-off bug fixes,” Microsoft says.

Since 2013, Microsoft has changed its bug bounty rewards policies several times, to offer monetary payments even for bugs that had already been discovered internally, and to make it clearer for researchers what vulnerability reports are eligible.

The award amounts were increased as well, concentrating on flaws with increased customer impact, and patching times have been shortened, the tech giant says.

“Today, incentives and partnership are baked into our company’s vulnerability disclosure program. Every report that is triaged, assessed, and fixed is reviewed for potential bounty eligibility. There is no need to register, no need to sign up, everyone is invited,” the company notes.

Related: Microsoft Offers Up to $15,000 in New AI Bug Bounty Program

Related: Hacker Conversations: Natalie Silvanovich From Google’s Project Zero

Related: Google Announces Bug Bounty Program and Other Initiatives to Secure AI

https://www.securityweek.com/microsoft-paid-out-63-million-since-launch-of-first-bug-bounty-program-10-years-ago/