InfoSec and Compliance – With 20 years of blogging experience, DISC InfoSec blog is dedicated to providing trusted insights and practical solutions for professionals and organizations navigating the evolving cybersecurity landscape. From cutting-edge threats to compliance strategies, this blog is your reliable resource for staying informed and secure. Dive into the content, connect with the community, and elevate your InfoSec expertise!
The Google Open Source Team scanned the Maven Central Java package repository and found that 35,863 packages (8% of the total) were using versions of the Apache Log4j library vulnerable to Log4Shell exploit and to the CVE-2021-45046 RCE.
āMore than 35,000 Java packages, amounting to over 8% of the Maven Central repository (the most significant Java package repository), have been impacted by the recently disclosed log4j vulnerabilities (1, 2), with widespread fallout across the software industry.ā reads the report published by Google.āAs far as ecosystem impact goes, 8% is enormous.ā
The Google experts used the Open Source Insights, a project used to determine open source dependencies, to assess all versions of all artifacts in the Maven Central Repository.
The experts pointed out that the direct dependencies account for around 7,000 of the affected packages. Most of the affected artifacts are related to indirect dependencies.
āThe deeper the vulnerability is in a dependency chain, the more steps are required for it to be fixed. The following diagram shows a histogram of how deeply an affected log4j package (core or api) first appears in consumers dependency graphs.ā reads the post published by the researchers. āFor greater than 80% of the packages, the vulnerability is more than one level deep, with a majority affected five levels down (and some as many as nine levels down). These packages will require fixes throughout all parts of the tree, starting from the deepest dependencies first.ā
But since the vulnerability was disclosed, 13% of all vulnerable packages have been fixed (4,620).
How long will it take for this vulnerability to be fixed across the entire ecosystem?
As Christmas 2021 approaches, spare a thought for your sysamins, for your IT team, and for your cybersecurity staff.
There may be plenty of mice stirring all through the IT house right up to Christmas Eveā¦
ā¦because thatās the deadline set by the US Cybersecurity and Infrastructure Security Agency (CISA) for patching the infamous Log4Shell vulnerability, a dangerously exploitable flaw in Apacheās widely used Log4j (Logging for Java) programming toolkit.
Since news first broke of the problem on 09 December 2021, Apache has a-patched the code not once but three times, variously fixing CVE-2021-44228 with version 2.15.0, quickly followed by 2.16.0 to fix a related bug dubbed CVE-2021-45046, foillowed quickly yet again by 2.17.0 to deal with CVE-2021-45105.
Why the pressure from CISA? Why the rush when weāre supposed to enjoying a global holiday season? Why not wait until New Year and deal with things then?
Hereās why your sysadmins are taking one (three, actually) for the teamā¦
Well, in case you missed it, the renowned OpenSSL cryptographic toolkit ā a free and open source software product that weāre guessing is installed somewhere between one and three orders of magnitude more widely than Log4J ā also published updates this week.
OpenSSL 1.1.1m replaces 1.1.1l (those last characters are M-for-Mike and L-for-Lima), and OpenSSL 3.0.1 replaces 3.0.0.
In case you were wondering, the popular X.Y.Z versioning scheme used by OpenSSL 3 was introduced at least in part to avoid the confusion caused by the trailing letter in the earlier version ānumberingā system. As for OpenSSL 2, there wasnāt one. Only the 1.1.1 and the 3.0 series are currently supported, so updating versions such as OpenSSL 1.0.x means jumping to 1.1.1m, or directly to the OpenSSL 3 series.
āApplications may not behave correctlyā
The good news is that the OpenSSL 1.1.1m release notes donāt list any CVE-numbered bugs, suggesting that although this update is both desirable and important (OpenSSL releases are infrequent enough that you can assume they arrive with purpose), you probably donāt need to consider it critical just yet.
But those of you who have already moved forwards to OpenSSL 3 ā and, like your tax return, itās ultimately inevitable, and somehow a lot easier if you start sooner ā should note that OpenSSL 3.0.1 patches a security risk dubbed CVE-2021-4044.
As far as weāre aware, there are no viable known exploits for this bug, but as the OpenSSL release notes point out:
[The error code that may be returned due to the bug] will be totally unexpected and applications may not behave correctly as a result. The exact behaviour will depend on the application but it could result in crashes, infinite loops or other similar incorrect responses.
In theory, a precisely written application ought not to be dangerously vulnerable to this bug, which is caused by what we referred to in the headline as error conflation, which is really just a fancy way of saying, āWe gave you the wrong result.ā
Simply put, some internal errors in OpenSSL ā a genuine but unlikely error, for example, such as running out of memory, or a flaw elsewhere in OpenSSL that provokes an error where there wasnāt one ā donāt get reported correctly.
Instead of percolating back to your application precisely, these errors get āremappedā as they are passed back up the call chain in OpenSSL, where they ultimately show up as a completely different sort of error.
Amongst all the brouhaha about Log4Shell, itās easy to forget all the other updates that surround us.
Not only is it Patch Tuesday (keep your eye on our sister site news.sophos.com for the latest on that score later in the day)ā¦
ā¦but itās also time to check your Apple devices, because Apple just pushed out a slew of its they-arrive-when-theyāre-ready-and-donāt-expect-any-warning security patches.
As for iOS 14 and iOS 12, which are the official previous and pre-previous iPhone operating systems (in the same way that Big Sur and Catalina are the previous incarnations of macOS), thereās no sign of any updates for them.
Observant readers will notice that the URLs in the list above form an unbroken numeric sequence except for a gap at HT212977, so whether thatās a space left open for a delayed update for iOS 14 or not we canāt tell youā¦
ā¦but we did notice that Appleās main security noticeboard page, HT201222, still [2021-12-14T12:00Z] doesnāt mention the updates listed above.
In the past, weāve noticed an apparent correlation between delayed updates for individual platforms and delayed listings on HT201222, but we have no idea whether that is coincidence rather that true correlation, or a desire on Appleās part to hold off updating the central listing until all the new versions can be displayed in one go.
(Apple, as you know, has an official policy of saying as little as possible about updates and update cycles, so we shall have to wait and see.)
Experts warn that threat actors are actively attempting to exploit a second bug disclosed in the popular Log4j logging library.
American web infrastructure and website security company Cloudflare warns that threat actors are actively attempting to exploit a second vulnerability, tracked as CVE-2021-45046, disclosed in the Log4j library.
The CVE-2021-45046 received a CVSS score of 3.7 and affects Log4j versions from 2.0-beta9 through 2.12.1 and 2.13.0 through 2.15.0 (which was released to fix CVE-2021-44228).
The Apache Software Foundation (ASF) has already released a patch for the Log4Shell vulnerability (CVE-2021-44228), but this fix partially address the flaw in certain non-default configurations. An attacker with control over Thread Context Map (MDC) input data when the logging configuration uses a non-default Pattern Layout with either a Context Lookup (for example, $${ctx:loginId}) or a Thread Context Map pattern (%X, %mdc, or %MDC) can craft malicious input data using a JNDI Lookup pattern triggering a denial of service (DOS) condition.
Both issues were assessed with the release of Log4j 2.16.0 version that addresses the CVE-2021-45046 by removing support for message lookup patterns and disabling JNDI functionality by default.
āHot on the heels of CVE-2021-44228 a second Log4J CVE has been filed CVE-2021-45046. The rules that we previously released for CVE-2021-44228 give the same level of protection for this new CVE.ā states CloudFlare.āThis vulnerability is actively being exploited and anyone using Log4J should update to version 2.16.0 as soon as possible, even if you have previously updated to 2.15.0. The latest version can be found on the Log4J download page.ā
The bad news are not ended, because researchers at security firm Praetorian warned of a third security vulnerability the Log4j version 2.15.0 that was released to fix the initial Log4Shell.
This third vulnerability can be exploited by attackers to exfiltrate sensitive data in certain circumstances.
āHowever, in our research we have demonstrated that 2.15.0 can still allow for exfiltration of sensitive data in certain circumstances. We have passed technical details of the issue to the Apache Foundation, but in the interim, we strongly recommend that customers upgrade to 2.16.0 as quickly as possible.ā states the post published by Praetorian.
Secure By Design
Secure Software Development Fundamentals Professional Certificate
The recent discovery of a second Log4j vulnerability (CVE-2021-45046) has shown that the fix to address CVE-2021-44228 in Apache Log4j 2.15.0 was incomplete in certain non-default configurations.
This vulnerability could allow attackers to craft malicious input data using a JNDI Lookup pattern, resulting in a denial of service (DoS) attack.
āNote that previous mitigations involving configuration such as to set the system property ālog4j2.noFormatMsgLookupā to ātrueā do NOT mitigate this specific vulnerability,ā the Apache Log4j security team noted.
āLog4j 2.16.0 fixes this issue by removing support for message lookup patterns and disabling JNDI functionality by default. This issue can be mitigated in prior releases (<2.16.0) by removing the JndiLookup class from the classpath (example: zip -q -d log4j-core-*.jar org/apache/logging/log4j/core/lookup/JndiLookup.class).” The team advises users either to upgrade to version 2.12.2 (for Java 7) or 2.16.0 (for Java 8 or later), in which the Message Lookups feature has been removed and access to JNDI has been disabled by default, and explained why some of the mitigation measures shared a few days ago are incomplete.
Active exploitation
PoCs are constantly popping up on GitHub and getting forked. GitHub is steadily working on removing them, but the proverbial cat is now out of the bag, and there is no going back.
Exploitation attempts detected so far in the wild can be tied to ransomware groups and access brokers, botnet herders (delivering coin miners), and nation-backed APTs.
As we continue to monitor threats taking advantage of the CVE-2021-44228 Log4j 2 vulnerability, weāre seeing activity ranging from experimentation to exploitation from multiple groups, including nation-state actors and access brokers linked to ransomware: https://t.co/WWSxGvaiDy
āThe way modern products are built is using a big hierarchy of dependencies, where developers use libraries written by third-party companies and engineers to speed up the software release process. Log4J is an extremely basic library that allows log writing in Java applications. The way CVE-2021-44228 affects comes in 3 layers ā cloud products that directly use the Log4J, web applications that use libraries that use Log4J, and off-the-shelf software which is internally deployed on customer servers and endpoints,ā says Michael Assraf, CEO at Vicarius.
āAs fixing and deploying cloud applications can be fast, updating libraries that use Log4J can break functionality unless done with caution. The most problematic fixes are internally deployed software, which will have to wait for a vendor update or a security patch, in that scenario customers are advised to wait on further vendor guidance and as of right now are helpless in reacting. Examples include: Elasticsearch, Intellij IDE, Jira Confluence, Apache Tomcat, Minecraft, Apache Hadoop, Eclipse IDE, and many more.ā
Gallagher says that the most immediate priority for defenders is to reduce exposure by patching and mitigating all corners of their infrastructure and investigate exposed and potentially compromised systems.
āWhere systems have been identified as vulnerable, defenders should run an incident response process and monitor for signs of remote access trojans such as C2 call-backs. Secrets stored on exposed systems should also be rotated, particularly if they are exposed in environment variables. Lastly, consider critical third party vendors who may also be at risk,ā he advised.
Mathew Eble, VP of Services at Praetorian, also warned the issue will be prone to false negatives.
āExternally there is no way to cover all the possible paths that exploitation can take. Even when external scanning tools get more sophisticated in how they identify the issue, we strongly advocate not relying on scan results as strong indicator of your risk,ā he noted.
This recommendation is based on four issues the company has confirmed when working with customers. Based on this, they have expanded their initial recommendations for defenders.
Secure By Design
Secure Software Development Fundamentals Professional Certificate
Over 1 million companies worldwide and over 731,000 companies in the U.S.Ā use Office 365, and though Microsoft offers no hard stats,Ā some sourcesĀ suggest there are over 90,000 Microsoft partners facilitating services and products for clients. Itās no wonder, then, that vulnerabilities in Microsoft solutions are an attractive attack vector.
So far in 2021, the 12 most notable critical Microsoft vulnerabilities fall within five major threat categories:
CISA adds Log4Shell Log4j flaw to the Known Exploited Vulnerabilities Catalog
The U.S. CISA added 13 new vulnerabilities to the Known Exploited Vulnerabilities Catalog, including Apache Log4Shell Log4j and Fortinet FortiOS issues.
Below is the list of new vulnerabilities added to the Known Exploited Vulnerabilities Catalog, which is the list of issues frequently used as attack vector by threat actors in the wild and that pose significant risk to the federal enterprise.
Red Hat Linux JBoss Seam 2 Remote Code Execution Vulnerability
6/10/2022
The CVE-2021-44228 flaw made the headlines last week, after Chinese security researcher p0rz9 publicly disclosed a Proof-of-concept exploit for the critical remote code execution zero-day vulnerability (aka Log4Shell) that affects the Apache Log4j Java-based logging library.
The impact of the issue is devastating, thousands of organizations worldwide are potentially exposed to attacks and security experts are already reported exploitation attempts in the wild.
CISA also warns of a recently disclosed arbitrary file download vulnerability in FortiOS, tracked as CVE-2021-44168, that is actively exploited.
āA download of code without integrity check vulnerability [CWE-494] in the āexecute restore src-visā command of FortiOS may allow a local authenticated attacker to download arbitrary files on the device via specially crafted update packages.ā reads the advisory published by Fortinet. āFortinet is aware of an instance where this vulnerability was abused and recommends immediately validating your systems for indicators of compromiseā
This books explains how to introduce the security into theĀ SDLC; how to introduce abuse cases and security requirements in the requirements phase; and how to introduce risk analysis (also known as Threat Modeling) in the design phase and software qualification phase. I really think that each software developer should at least read the first chapter of the book where the authors explain why the old way of securing applications (seeing software applications as āblack boxesā that can be protected using firewalls and IDS/IPS) cannot work anymore in today’s software landscape.Ā
Threat actors are exploiting a recently addressed server-side request forgery (SSRF) vulnerability, tracked as CVE-2021-40438, in Apache HTTP servers.
The CVE-2021-40438 flaw can be exploited against httpd web servers that have the mod_proxy module enabled. A threat actor can trigger the issue using a specially crafted request to cause the module to forward the request to an arbitrary origin server.
The vulnerability was patched in mid-September with the release of version 2.4.49, it impacts version 2.4.48 and earlier.
āA crafted request uri-path can cause mod_proxy to forward the request to an origin server choosen by the remote user.ā reads theĀ change logĀ for version 2.4.49.
Since the public disclosure of the vulnerability, several PoC exploits for CVE-2021-40438 have been published.
Now experts from Germanyās Federal Office for Information Security (BSI) and Cisco are warning of ongoing attacks attempting to exploit the vulnerability.
Cisco published a security advisory to inform its customers that it is investigating the impact of the issue on its products. The issue impacts Prime Collaboration Provisioning, Security Manager, Expressway series and TelePresence Video Communication Server (VCS) products. However, the IT giant states that it is still investigating its product line.
āIn November 2021, the Cisco PSIRT became aware of exploitation attempts of the vulnerability identified by CVE ID CVE-2021-40438.ā reads theĀ security advisoryĀ published by CISCO.
The German BSI agency also published an alert about this vulnerability, it is aware of at least one attack exploiting this vulnerability.
āThe BSI is aware of at least one case in which an attacker was able to do so through exploitation the vulnerability to obtain hash values of user credentials from the victimās system. The vulnerability affects all versions of Apache HTTP Server 2.4.48 or older.ā reads theĀ alertĀ published by the BSI.
Google TAG researchers discovered that threat actors leveraged a zero-day vulnerability in macOS in a watering hole campaign aimed at delivering malware to users in Hong Kong. The attackers exploited a XNU privilege escalation vulnerability (CVE-2021-30869) unpatched in macOS Catalina
The watering hole campaign targeted websites of a media outlet and important pro-democracy labor and political group. The researchers discovered that attackers deployed on the sites hosted two iframes that were used to serve iOS and macOS exploits to the visitors.
The experts believe that the attack was orchestrated by a nation-state actor, but did not attribute the campaign to a specific APT group.
The attack was discovered in late August, the nature of the targets and the level of sophistication of the attack suggests the involvement of a China-linked threat actor.
āTo protect our users, TAGĀ routinely huntsĀ for 0-day vulnerabilities exploited in-the-wild. In late August 2021, TAG discovered watering hole attacks targeting visitors to Hong Kong websites for a media outlet and a prominent pro-democracy labor and political group. The watering hole served an XNU privilege escalation vulnerability (CVE-2021-30869) unpatched in macOS Catalina, which led to the installation of a previously unreported backdoor.ā reads the analysis published by Google. āAs is our policy, we quickly reported this 0-day to the vendor (Apple) andĀ a patch was releasedĀ to protect users from these attacks.ā
US CISA is urging vendors to addressĀ BrakToothĀ flaws after security researchers have released public exploit code and a proof of concept tool to test Bluetooth devices against potential Bluetooth exploits.
āOn November 1, 2021, researchers publicly released aĀ BrakTooth proof-of-concept (PoC) toolĀ to test Bluetooth-enabled devices against potential Bluetooth exploits using the researcherās software tools. BrakToothāoriginally disclosed in August 2021āis a family of security vulnerabilities in commercial Bluetooth stacks. An attacker could exploit BrakTooth vulnerabilities to cause a range of effects from denial-of-service to arbitrary code execution.āĀ reads CISAās advisory.
āCISA encourages manufacturers, vendors, and developers to reviewĀ BRAKTOOTH: Causing Havoc on Bluetooth Link ManagerĀ and update vulnerable Bluetooth System-on-a-Chip (SoC) applications or apply appropriate workarounds.ā
BrakToothĀ is a set of 16 security flaws in commercial Bluetooth stacks that can be exploited by threat actors to execute arbitrary code and crash the devices via DoS attacks.
Security Threats and Countermeasures in Bluetooth-Enabled Systems
Cybersecurity researchers warn of a now-patched critical remote code execution (RCE) vulnerability, tracked as CVE-2021-22205, in GitLabās web interface that has been actively exploited in the wild.
The vulnerability is an improper validation issue of user-provided images the can lead to arbitrary code execution. The vulnerability affects all versions starting from 11.9.
āAn issue has been discovered in GitLab CE/EE affecting all versions starting from 11.9. GitLab was not properly validating image files that is passed to a file parser which resulted in a remote command execution. This is a critical severity issue (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9). It is now mitigated in the latest release and is assignedĀ CVE-2021-22205.ā reads theĀ advisoryĀ published by GitLab.
GitLab addressed the vulnerability on April 14, 2021, with the release of 13.8.8, 13.9.6, and 13.10.3 versions.
The vulnerability was reported by the expertĀ vakzzĀ through the bug bounty program of the company operated through the HackerOne platform.
The vulnerability was actively exploited in the wild, researchers from HN Security described an attack one of its customers. Threat actors created two user accounts with admin privileges on a publicly-accessible GitLab server belonging to this organization. The attackers exploited the flaw to upload a malicious payload that leads to remote execution of arbitrary commands.
āMeanwhile, we noticed that a recently released exploit forĀ CVE-2021-22205Ā abuses the upload functionality in order to remotely execute arbitrary OS commands. The vulnerability resides inĀ ExifTool, an open source tool used to remove metadata from images, which fails in parsing certain metadata embedded in the uploaded image, resulting in code execution as describedĀ here.ā reads theĀ analysisĀ published by HN Security.
The flaw was initially rated with a CVSS score of 9.9, but the score was later changed to 10.0 because the issue could be triggered by an unauthenticated attackers.
Researchers from Rapid7Ā reportedĀ that of the 60,000 internet-facing GitLab installations:
Facebook announced to have designed a new tool, named SSRF Dashboard, that allows security researchers to search for Server-Side Request Forgery (SSRF) vulnerabilities.
Server-side request forgery is a web security vulnerability that allows an attacker to induce the server-side application to make HTTP requests to an arbitrary domain chosen by the attacker.
āIn a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within the organizationās infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data such as authorization credentials.ā
āThis tool is a simple UI where researchers can generate unique internal endpoint URLs for targeting. The UI will then show the number of times these unique URLs have been hit as a result of a SSRF attempt. Researchers can leverage this tool as part of their SSRF proof of concept to reliably determine if they have been successful.ā states Facebook.
SSRF Dashboard allows researchers to create unique internal endpoint URLs that could be targeted by SSRF attacks and determine if they have been hit. The tool allows researchers to test their SSRF proof-of-concept (PoC) code.
Pentesters could report any SSRF flat to the company by including the ID of the SSRF attempt url that they used along with their PoC.
Additional information on the utility can be found here.
The development team behind the Git GUI client GitKraken has fixed a vulnerability that was leading to the generation of weak SSH keys. The developers addressed the flaw with the release of version 8.0.1.
The issue resides in the open-source library used by the Git GUI client to generate SSH keys, all the keys generated using versions 7.6.x, 7.7.x, and 8.0.0 of GitKraken are potentially affected.
The latest version of the Git GUI client (version 8.0.1) uses a new SSH key generation library.
āThis issue only affects GitKraken users who generated SSH keys through the GitKraken interface using versions 7.6.x, 7.7.x,Ā 8.0.0. If you are not sure what version you used to generate your SSH key, we encourage you to renew your key through the following process.āĀ reads the advisory.
āAffected users need to:
1. Remove all old generated SSH keys stored locally.
2. Generate new SSH keys using GitKraken 8.0.1, or later, for each of your Git service providers.ā
The development team already notified the Git hosting service providersĀ GitHub,Ā Bitbucket,Ā GitLab, and Azure DevOps, they also revoked the weak public keys used.
The development team is not aware of any accounts being compromised due to this weakness.
You donāt get one for a while, and then three come at once.
For buses on busy urban routes, at least, the explanation of the phenomenon goes something like this.
If three buses start out travelling the same route together in a nicely spaced sequence, then the first one is most likely to be the slowest, because it will be stopping to scoop up most of the waiting passengers, while the ones behind will tend to travel faster because they need to stop less often or for shorter periods.
So buses naturally tend to scrunch up and arrive in bursts.
Burst-mode software patches
When it comes to software patches, however, the problem often works the other way around.
If the first patch arrives too quickly, then it may not have been reviewed or tested quite as much as you might like.
So itās not so much that the next patch in the queue catches up because the first one is too slow, but that the next one has to be completed in a rush to keep upā¦
ā¦and, if you arenāt careful, then that second patch might itself beget a third patch, needed to patch the patch that patched the first patch.
Three Apache buses
And thus with Apache: just two days ago, we reported aĀ path validation bugĀ dubbedĀ CVE-2021-41773Ā that was introduced in Apache 2.4.49:
A proof of concept exploit for two authentication bypass vulnerabilities in Dahua cameras is available online, users are recommended to immediately apply updates.
A remote attacker can exploit both vulnerabilities by sending specially crafted data packets to the vulnerable cameras.
āThe identity authentication bypass vulnerability found in some Dahua products during the login process. Attackers can bypass device identity authentication by constructing malicious data packets.ā reads theĀ advisoryĀ published by the vendor in early September.
The flaw received a CVSS v3 score of 8.1, the vendor recommended its customers to install security updates.
The list of affected models is very long, it includes IPC-X3XXX,HX5XXX, HUM7XX, VTO75X95X, VTO65XXX, VTH542XH, PTZ Dome Camera SD1A1, SD22, SD49, SD50, SD52C, SD6AL, Thermal TPC-BF1241, TPC-BF2221, TPC-SD2221, TPC-BF5XXX, TPC-SD8X21, TPC-PT8X21B, NVR1XXX, NVR2XXX, NVR4XXX, NVR5XXX, NVR6XX.
It could be quite easy for threat actors in the wild to find exposedĀ DahuaĀ devices using a search engine likeĀ ShodanĀ and attempt to hack them using the available PoC code. In order to protect Dahua devices, users have to install the latest firmware version.
The security researcher Jose Rodriguez discovered a new lock screen vulnerability for iOS 15 (& iOS 14.8) that has yet to be fixed.
The security researcher Jose Rodriguez (@VBarraquito) discovered a new lock screen vulnerability for iOS 15 (& iOS 14.8) that has yet to be addressed by Apple. A threat actor with physical access to a vulnerable device can access Notes via Siri/Voice Over.
Rodriguez explained that in real incidents, unattended or stolen devices with a lock screen bypass vulnerability are exposed to attacks that could leverage a lock screen vulnerability to access sensitive information.
This specific type of vulnerability represents a serious threat to individuals and organizations, for this reason, the expert suggests including their research when conducting a mobile pen-testing assessment.
The expert disclosed details about the lock screen bypass vulnerability after Apple downplayed similar flaws, tracked as CVE-2021-1835 and CVE-2021-30699, reported by the researcher earlier this year.
The flaws allowed an attacker to access instant messaging apps like WhatsApp or Telegram even while the mobile device was locked.
Rodriguez explained that Apple partially fixed the issue and did not involve him in the test of the released patch.
Then the expert proposed a variant of the same bypass issue that leverages Apple Siri and VoiceOver services to access the Notes app.
In hopes Apple realizes that is being tightwad rewarding security bug reports, and reconsider the bounties. https://t.co/g6TEIWmVDJ
It should be noted that this is a local privilege escalation (LPE) vulnerability, which means that you need to have a Razer devices and physical access to a computer. With that said, the bug is so easy to exploit as you just need to spend $20 on Amazon for Razer mouse and plug it into Windows 10 to become an admin.
![INSTRUCTIONS FOR SET UP SECURITY POLICY WEB SERVER APACHE by [David Du]](https://m.media-amazon.com/images/I/41uFA2ri8YL.jpg)
![OWASP Testing Guide v4 by [OWASP OWASP]](https://m.media-amazon.com/images/I/419Ozw6vGtL.jpg)
