A targeted campaign delivering the ZLoader banking trojan is spreading via Google AdWords, and is using a mechanism to disable all Windows Defender modules on victim machines. According to SentinelLabs, hackers are lowering rates of detection by using an infection chain for the campaign that also includes the use of a signed dropper with a backdoored version of the Windows utility wextract.exe to embed the ZLoader payload itself.

ZLoader is not new, but tis exploit addition is. It has been noted as typical a banking trojan which implements web injection to steal cookies, passwords and any sensitive information. It attacks users of financial institutions all over the world and has also been used to deliver ransomware families like Egregor and Ryuk. It also provides backdoor capabilities and acts as a generic loader to deliver other forms of malware.

ZLoader Infection Chain Starts with Google AdWords To target victims, the malware is spread from a fake Google advertisement (published through Google AdWords) for various software; the lures include Discord, Java plugins, Microsoft’s TeamViewer and Zoom.

For example, when someone Googles “Team Viewer download” a fake advert appears in AdWords (advert has already been taken down, but it does indicate that diligence is need to make sure the URL and company is correct for any downloads), an advertisement shown by Google on the search engine, that redirects the clicker to a fake TeamViewer site under the attacker’s control. From there, the user can be tricked into downloading a fake installer in a signed MSI format. Current versions have a signed timestamp of Aug. 23, but this is likely to change as it is exposed.

SentinelLabs advise that “It appears that the cybercriminals managed to obtain a valid certificate issued by Flyintellect Inc., a Software company in Brampton, Canada”; “[t]he company was registered on 29 June 2021, suggesting that the threat actor possibly registered the company for the purpose of obtaining those certificates”.

Bypassing and disabling Windows Defender check The downloaded and legitimately signed .MSI file is of course not an installer for legitimate software, but is rather the first-stage dropper for the malware. It runs an installation wizard that creates the following directory: C:Program Files (x86)Sun Technology NetworkOracle Java SE, and saves a .BAT file appropriately called “setup.bat” and then executes the built-in Windows cmd.exe function to execute that file. Users often see the flash of a cmd prompt as Microsoft often use it during windows updates, so do not suspect anything. The executed .BAT then begins stage two and downloads a second-stage dropper that initiates the third stage of infection by executing a script called “updatescript.bat”.

The third stage dropper contains logic impairment to shutdown defenses of the machine by disabling all the Windows Defender modules through the PowerShell cmdlet Set-MpPreference. It then adds exclusions, such as regsvr32, *.exe, *.dll, with the cmdlet Add-MpPreference to hide all the components of the malware from Windows Defender.

Once completed, stage four is executed with the download of the .EXE from URL (hxxxURL://pornofilmspremium.com/tim.exe) which is saved and executed through the Windows explorer.exe function.

At this point the attacker is able to break the parent/child correlation often used by endpoint detection and response (EDRs). As the The tim.exe binary is actually a backdoored version of the legitimate Windows utility wextract.exe but with the hackers additional code, hackers can now legitimately execute the malicious batch file with the name “tim.bat” that runs a short script to download the final ZLoader DLL payload, with the name tim.dll. This final payload is executed using the legitimate Windows function regsvr32, which allows the attackers to proxy the execution of the DLL through a signed binary by Microsoft and execute the functions to exploit the machine.

Tim.bat also downloads another script, called “nsudo.bat” to perform multiple operations to elevate privileges on the system and impair defenses as follows:

1. It checks if the current context of execution is privileged by verifying the access to the SYSTEM hive.
2. It implements an auto elevation VBScript that aims to run an elevated process in order to make system changes.

The snippet of the script in charge of the UACPrompt feature is as follows:

:UACPrompt
  echo Set UAC = CreateObject^("Shell.Application"^) > "%temp%getadmin.vbs"
  set params = %*:"="
  echo UAC.ShellExecute "cmd.exe", "/c %~s0 %params%", "", "runas", 1 >> "%temp%getadmin.vbs"
"%temp%getadmin.vbs"
  del "%temp%getadmin.vbs"
  exit /B

3. Once the elevation occurs, the script is run with elevated privileges to perform the steps of disabling Windows Defender on a persistent basis by making sure that the “WinDefend” service is deleted at the next boot through the utility NSudo, and completely disables Microsoft’s User Account Control (UAC) security.

The nsudo.bat script also completely disables UAC by setting the following registry key to 0 (zero):

HKEY_LOCAL_MACHINESOFTWAREMicrosoftWindowsCurrentVersionPoliciesSystemEnableLUA

4. After executing these functions it forces a system restart, so that the changes take place and users are unaware.

The purpose of the exploits is to tie the machine into the botnet for bitcoin mining and other operations including DDos attack's as the following extract of DDos URL's show:

@https://commerzbank.de @https://.de//entry* @https://.de/banking-/portal?* @https://.de/banking-/portal;* @https://.de/portal/portal @https://.de/privatkunden/ @https://.deabmelden* @https://.de/de/home @https://.de/en/home @https://.de/fi/home @https://banking.sparda.de @https://banking.sparda- @https://banking.sparda.de/wps/loggedout.jsp @https://meine.deutsche-bank.de/trxm/db* @https://banking.berliner-bank.de/trxm* @https://meine.norisbank.de/trxm/noris @https://targobank.de @https://banking4.anz.com/IBAU/BANKAWAY @https://banking.westpac.com.au/ @https://www1.my.commbank.com.au/netbank/Portfolio/Home/ @https://ibanking.stgeorge.com.au/ibank/ @https://ibanking.banksa.com.au/ibank/ @https://ibanking.bankofmelbourne.com.au/ibank/ @https://online.macquarie.com.au/ @https://ob.cua.com.au/ib/ @https://banking.bendigobank.com.au/banking @https://internetbanking.suncorpbank.com.au/ @https://www.ing.com.au/securebanking/ @https://ib.nab.com.au/ @https://online.beyondbank.com.au/ @https://ib.greater.com.au @www.independentreserve.com @www.coinspot.com.au

Google advise that if you come across any advert that redirects you should report it via the following:

https://support.google.com/google-ads/contact/vio_other_aw_policy https://safebrowsing.google.com/safebrowsing/report_phish/

Recommendations

1. At all time use an adblocker software to aid in disruption of this exploit.

I realize Google will not be happy about this, but until the system is fixed from such exploits, it is better to be safe. Google should consider formal verification, not just address location verification for advertisers. Perhaps verifying and monitoring advertising URLS may also be something they should consider?

2. Do not click on ads. Manually go to the advertisers company rather than clicking on the advert.

Again Google will be unhappy as this is their revenue source. But until its fixed, and confirmed safe, AdWords is currently just another tool in the hackers toolbox

3. Verify the domain name and download link before clicking on a URL. Don't assume it is correct.

What is it? Spook.js is a new transient execution side channel attack which targets the Chrome web browser. We show that despite Google's attempts to mitigate Spectre by deploying Strict Site Isolation, information extraction via malicious JavaScript code is still possible in some cases.

In more detail, Spook.js is a fresh side channel attack that works on modern hardware to overcome Google Chrome/Chromium based browsers Site Isolation Protections. The purpose of the aforementioned protections is to prevent each browser tab from being able to see each others memory/storage allocation.

The reason that this is an issue is for example if you are doing something sensitive in one tab, like managing your bank account online, and a separate tab and/or windows you have a different site open that is infected with the spook.js vulnerability. the infected page can potentially read the information from the other tab, such as your banking page.

More specifically, an attacker-controlled webpage can know which other pages from the same websites a user is currently browsing, retrieve sensitive information from these pages, and even recover login credentials (e.g., username and password), especially when they are autofilled. Further the attacker can retrieve data from Chrome extensions (such as credential managers) if a user installs/executes a malicious extension (say when accessing a website with the exploit active).

Spook.js Demo 1 - Attacking Credential Managers

The underlying vulnerability spook.js exploits though is a previously revealed and currently unresolved hardware issue with all modern CPUs dating back at least 10-15 years ago or so. All CPUs come with a task scheduler that attempts to predict what tasks to run when. if manipulated, said task scheduler can be exploited by using timed attacks on the scheduler to determine what's in memory at the time of the attack.

While this sounds scary, it just means that when browsing sites of a sensitive nature it should be the only tab open on the PC on any chromium browser as long as the sensitive site is open.

This affects all forms of chromium browsers: MS Edge, Opera, Chrome, and others using the chromium code.

Current protection may exist in: Firefox, however, great caution should be used as further testing is on going to confirm, as the advanced settings show mitigation not a fix. So we recommend that the same recommendations below should be used in Firefox also.

Web developers can protect their sites against this exploit, but it is unclear as to when everyone will update the code, and there is no way to confirm if it has been done, so it is best to protect rathe than risk.

The exploit exist on both desktop and mobile devices, so you are not protected just by using your phone.

Recommendations

Be sure your browser is fully patched. Then follow these rules when using any browser.

1. Close all browsers to a clean start (as chrome stays active in the background if not fully closed, this is a must) when using anything that requires login information to your sensitive data (office file systems, banking, etc).
2. Do not open any other tab or browser while working in the risk sensitive environment
3. Close the browser when finished and start a fresh browser for research (being sure to close it if you need to access secure resources).
4. Disable autofill, and remove all autofill usernames and passwords.

BadAlloc is the name for a related group of RTOS (Real Time Operating System) vulnerabilities that target 25 platforms, with 23 related vulnerabilities. The result of the vulnerability being exploited varies based upon the target device/platform, but can vary from high hardware usage, limiting the operations of said affected device, to device firmware crashes and reboots. The vulnerability exploits a flaw in memory allocation within the device to achieve the above fault.

The error occurs in a range of IoT and ROT devices as well as Blackberry devices used in maritime and other government operations. A remote attacker could exploit CVE-2021-22156 to cause a denial-of-service condition or execute arbitrary code on affected devices, and in our review on the dark web, has been linked to malware designed to connect additional CPU power to bitcoin mining.

The issue was discovered in April 2021, but many devices still remain unpatched after the August 17 report at Cert USA. Many of the devices unpatched have mitigation responses that recommend to isolate the unit from the internet or simply take it offline until a patch is released or it is replaced.

Cert USA states:

• Apply available vendor updates.
• Minimize network exposure for all control system devices and/or systems, and ensure that they are not accessible from the Internet.
• Locate control system networks and remote devices behind firewalls, and isolate them from the business network.
• When remote access is required, use secure methods, such as Virtual Private Networks (VPNs), recognizing VPNs may have vulnerabilities and should be updated to the most current version available.
• Also recognize VPN is only as secure as its connected devices.

We would add:

1. Replace the device if possible
2. IoT devices with this vulnerability have been linked to exploit attacks for bitcoin malware, and care should be taken to reset the device to factory defaults once secured to be absolutely sure the system is clean.

This discovery has been credited by CISA to David Atch, Omri Ben Bassat, and Tamir Ariel from Microsoft Section 52.

Here is a listing of the affected operating systems and their status:

Amazon FreeRTOS, Version 10.4.1 Update available

Apache Nuttx OS, Version 9.1.0 Update available

ARM CMSIS-RTOS2, versions prior to 2.1.3 Update in progress

ARM Mbed OS, Version 6.3.0 Update available

ARM mbed-ualloc, Version 1.3.0 no longer supported and no fix will be issued

BlackBerry QNX SDP Versions 6.5.0 SP1 and earlier Update available

BlackBerry QNX OS for Safety Versions 1.0.1 and earlier safety products compliant with IEC 61508 and/or ISO 26262 Update available

BlackBerry QNX OS for Medical Versions 1.1 and earlier safety products compliant with IEC 62304 Update available

Cesanta Software Mongoose OS, v2.17.0 Update available

eCosCentric eCosPro RTOS, Versions 2.0.1 through 4.5.3 Update available

Google Cloud IoT Device SDK, Version 1.0.2 Update available

Media Tek LinkIt SDK, versions prior to 4.6.1 Vendor will directly provide the fix, fix not available for free users

Micrium OS, Versions 5.10.1 and prior Update available

Micrium uC/OS: uC/LIB Versions 1.38.xx, Version 1.39.00 Update available

NXP MCUXpresso SDK, versions prior to 2.8.2 Update available

NXP MQX, Versions 5.1 and prior Update available

Redhat newlib, versions prior to 4.0.0 Update available

RIOT OS, Version 2020.01.1 Update available

Samsung Tizen RT RTOS, versions prior 3.0.GBB Update available

TencentOS-tiny, Version 3.1.0 Update available

Texas Instruments CC32XX, versions prior to 4.40.00.07 Update available

Texas Instruments SimpleLink MSP432E4XX Update available

Texas Instruments SimpleLink-CC13XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC26XX, versions prior to 4.40.00 Update available

Texas Instruments SimpleLink-CC32XX, versions prior to 4.10.03 Update available

Texas Instruments SimpleLink MSP432E4 No update currently planned

Uclibc-NG, versions prior to 1.0.36 Update available

Windriver VxWorks, prior to 7.0 Update in progress

Zephyr Project RTOS, versions prior to 2.5 Update available

With the loss of business due to Covid-19, cryptocurrency has had a resurgence in uptake. Offers of better mining, and group mining from legitimate organizations have seen small business jump on the opportunity to increase revenue through currency mining. Unfortunately, this has also seen an increase in activity for exploits though the mining software.

History to new activity In the past the threat was confined to crypto hijacking. Sending a malware application to the unsuspecting user, and then installing, unaware to the user, an application that would start mining - commonly called cryptojacking. This prompted increases in malware protection and protection policies, that saw the problem move to more sophisticated means through social engineering and so on.

However, with the increase in unemployed workers and business loss due to covid-19, personal computers started to be assigned to the task of crypto mining to try and get people out of difficult spots. This increase in activity did not go unnoticed, and dark web actors turned their minds to exploiting these new users through their own uptake of mining software. This was great news to the hackers, as they no longer needed to force the malware or exploits as users voluntarily downloaded it through legitimate actors.

Industry Knowledge Before I explain how it is important to note that the exploit being deployed is known in the core code, and it appears that it has been unfixed as it allows Bitcoin to increased profits, or so some of the actors who exploit the code explain. They claim that they do this to bring awareness as bitcoin is ignoring their statements to them of how it exist and what it does.

The exploit So how does it work? Its very simple really, a user engaging in mining, signs up to a group management site and downloads a software mining application so that they can mine cryptocurrency in the group, or cloud pool - a pool they add from the machines they have, or friends and do on (cudominer is one as an example). The installed mining application reports to the sever and starts the mining process for the group based on the parameters and hardware set in the management site. Simple so far, the miner then goes off and starts mining and the user can see the hashes being generated and the approximate bitcoin currency they should earn in the month.

The exploit works in a two fold manner. First it allows the dark web to see your miners IP and add it to the botnet network. An attacker can then inject set of code to exploit your machine to process mining for other users not in your group, but are reported as your group in the form of a fee, which is then record to bitcoin as a legitimate fee. This fee is delivered to the botnet manager application available for purchase on the dark web by the actor setting-up the exploit.

The second issue relates to the code continuing even after closing the application. A user may close the miner, and think, right now I can do something else and leave it be. Unknown to the user, the miner may be turned on remotely by the exploiter and grab bitcoin from your machine/pool, and you will never know as it stays under the radar by not using 100% of the processor, it only becomes noticeable when using another application needing high resources, such as gaming, as it begins to slowdown or periodically freeze. Harder to notice on higher end gaming hardware due to the speed of allocating resources as calculations which appears more as latency than cpu/gpu load. What's worse, is you pay the power bill, they get 100% of the unseen transactions. The management software never sees it occurring, but the bitcoin is calculated to the exploited application and sent to the actor exploiting the flaw which is calculated off through bitcoin as legitimate due to the setup pool design.

The software is successful because you, the installer, have approved it to bypass your defenses (Windows defender etc) at install as it reports legitimately as a signed MS application from a legitimate company who is also likely to be unaware of the exploit as it is part of the core code working as intended.

Testing We actively tested the issue above after discovering websites on the dark web that advertised the exploits for use.

In our tests we saw as follows: 1 Active exploit to a large pool of devices that allowed for the collection of 2.5 bitcoin, undermining the value of bitcoin currency. 2 Active exploit of the miner application in Windows 10 that could not be closed in the task manager. 3 On reboot, the exploited miners became active again, meaning the miner code had been lodged into the startup code of the OS.

We also express additional concerns arise as to weather this exploit could be used for other malicious purposes?

We notified cudominer of our discovery, with no response, and we have confirmed that the calculations are short the sums we calculated for load and mining allocation compared to the reported sum in cudominer manager.

Recommendations Uninstall immediately.

To uninstall 1. Reconfigure your miners default setting manually by disconnecting from the pools default, and disable startup. Check the miner manager is disabled in your startup tab under task manager. Then uninstall the software and check to confirm that the antimalware settings have been removed. Reboot and test again. 2. Reset of the antimalware back to default is also recommended, it is easier to re approve apps than have the exploit active.

If you must run If you must run the code, and we understand why you might need too, place the code on a computer that only operates this code, and make sure it is firewalled from your main network. When you have finished the mining for the period you allocated, physically shutdown and turn off the machine until you need it next.

Remember that the code exploit sends money to the botnet for any form of criminal activity, and to date Anon has advised over 100million in bitcoin has been generated to date, so run these miner managers is not recommended until this exploit is fixed.

HAProxy is a free to use server load balancing application or software addon. JFrog Security reported on September 7 2021, that a vulnerability in an Integer Overflow existed in versions 2.0 through 2.5 in the htx_add_header() and htx_add_trailer() due to a missing length check on the header name that makes it possible for an attacker to bypass all configured http-request HAProxy ACLs, and possibly other ACLs, to conduct an HTTP Request Smuggling attack. This attack allows an adversary to “smuggle” HTTP requests to the backend server, without the proxy server being aware of it.

The smuggled requests have various impacts, depending on HAProxy’s configuration and the backend web server configuration. It is reported that the execution of the vulnerability can or may:

• Bypass security controls, including any ACLs defined in HAProxy
• Gain unauthorized access to sensitive data
• Execute unauthorized commands or modifying data
• Hijack user sessions
• Exploit a reflected XSS vulnerability without user interaction

HTTP Request smuggling is based on interfering with the processing of HTTP requests between the frontend (i.e. HAProxy on a router) and the backend (being the server hosting the destination). An attacker typically exploits this technique by sending a specially crafted request that includes an additional request in its body. During a successful attack, the inner request is smuggled through the frontend, that considers it as only the request’s body, but in fact consist of an additional function hidden to the HAproxy frontend and is executed as a normal request by the backend.

In most cases, the smuggling technique is done by supplying both the Content-Length and Transfer-Encoding headers with contradicting lengths in the same request and aiming for parsing inconsistencies between the frontend and backend servers. In the original authors case, however, the attack was made possible by utilizing an integer overflow vulnerability that allowed reaching an unexpected state in HAProxy while parsing an HTTP request – specifically – in the logic that deals with Content-Length headers.

An important enabler condition that makes this class of attacks possible is that when the frontend server forwards HTTP requests to the backend, it uses the same established TCP connection instead of wasting time on opening and closing sockets. The requests are sent "back to back" and it is up to the backend server to decide where a request ends and the next one begins.

In our testing, the function can be protected against if the parse then reaches a server properly configured. However, where the server is a direct connection, ie no properly configured Apache or NGNIX, a direct Microsoft server port, then the execution is still possible.

As advised by HAProxy, the best solution is to upgrade to version 2.0.25, 2.2.17, 2.3.14 or 2.4.4 CVE-2021-40346, which provides a patch for such activity by adding size checks for the name and value lengths.

However, for security reasons HTTP traffic should by default be redirected to HTTPS, even if that needs to be done on the end server. This redirect will assist to remove the hidden execution where the patch above cannot be applied.

Recommendations If HAproxy cannot be immediately upgraded, HAProxy should have port 80 added as a https-redirect to rule "scheme https", or in the alternative, when accessing the end server, Apache or NGNIX redirect to HTTPS.

Where HAproxy cannot be upgraded at all, and a Https redirect is also not possible, due to say, vender firmware, the end server should be removed from HAProxy and the port dedicated in its connection to the end server until the hardware containing the firmware can be replaced. Even if this means web redetecting for clients.

An organization named EXPMON discovered an Office 365/2019 vulnerability on September 5th 2021. The vulnerability lies within MSHTML, which is the Microsoft Internet Explorer browser engine. The vulnerability itself is a Remote code execution (RCE) attack, allowing the attacker to remotely install malware on the target machine.

Source tweet

The exploit is performed by an attacker sending a user a modified .docx file. Said file will contain a script upon opening the document that will use the IE MSHTML engine to open the url programmed into the scripting in the .docx file.

Microsoft has recommended disabling scripts and active X execution, but we are not convinced this is enough due to the base IE11 code being left in the OS. Despite Microsoft not carrying over the IE coding from legacy Edge when they switched to the new Chromium based Edge browser, having legacy IE11 code within the OS still makes execution possible and we recommend removing the base IE11. This is, however, not a guarantee as Microsoft has not confirmed if the IE11 code exist in other parts of the OS, so the following prevention recommendations should always be followed:

Recommendation Internet Explorer 11, even if not showing on your computer, is likely still installed as a background app on your machine as Microsoft has maintained it for compatibility, it is recommended to remove it. You can do this by searching for windows features in the windows search bar. Uncheck the Internet Explorer 11 checkbox to remove "Internet Explorer" and IE11 code. Your PC should request a reboot, click reboot when prompted.

See walkthrough video here

If your business still requires use of Internet Explorer 11 for any reason, contact the developer of the program you are using to ask them to update their codebase to support modern web browsing.

It is important to remember that attachments are often insecure, and even if you have removed the above code, we continue to recommend not opening attachments unless you are absolutely sure of the source; and even then, only once you have confirmed that the source did send it.

The preferred approach is to use a sharing system such as our On The move server https://c-justice.com/odrsoftware.html available to all types of business, as one example; or other secure option instead of using attachments.

Bluetooth Classic (BT) protocol is a widely used wireless protocol in laptops, handheld devices, and audio devices. In the past few years, Bluetooth has come under scrutiny due to the discovery of several critical vulnerabilities. In this report, the authors disclose BrakTooth, a family of new security vulnerabilities in commercial BT stacks that range from denial of service (DoS) via firmware crashes and deadlocks in commodity hardware to arbitrary code execution (ACE) in certain IoTs.

As of the report date, 16 different vulnerabilities, which impact billions of devices that rely on Bluetooth Classic (BT) for communication have been uncovered. According to an academic paper from the University of Singapore, the bugs are found in the closed commercial BT stack used by at least 1,400 embedded chip components, that can lead to a host of attack types – mainly denial of service (DoS) via firmware crashes (the term “brak” is actually Norwegian for “crash”). One of the bugs can also lead to arbitrary code execution (ACE).

The team analyzed 13 pieces of BT hardware from 11 vendors; so far, there have been 20 CVEs assigned across them; with four vulnerabilities pending CVE assignments from Intel and Qualcomm. Some of the bugs are patched, others are in the process of being patched; but, researchers said in the paper, “it is highly probable that many other products (beyond the ≈1400 entries observed in Bluetooth listing) are affected by BrakTooth,” including BT system-on-chips (SoCs), BT modules or additional BT end products.

Potentially, billions of devices could be affected worldwide. BrakTooth report by Asset Group

Figure 1: An Illustration of the BT connection procedure. FHS stands for Frequency Hopping Synchronization, ID stands for Identity, LMP stands for Link Manager Protocol and ACL stands for Asynchronous Connection Less.

Figure 2: An Illustration of BrakTooth attack scenario

Figure 2 showcases the generic scenario in which BrakTooth attacks are performed. The attacker only requires (1) a cheap ESP32 development kit (ESP-WROVER-KIT [37]) with a custom (non-compliant) LMP firmware and (2) a PC to run the PoC tool. The PoC tool communicates with the ESP32 board via serial port (/dev/ttyUSB1) and launches the attacks according to the specified target BDAddress () and exploit name parameter ().

Furthermore, the PoC tool logs over-the-air (OTA) packets and checks the health of the target by getting a paging timeout (no response) or alternatively getting status directly from the target via a serial port, ssh connection, etc.

Researchers successfully forced ESP32 into erasing data housed in devices’ non-volatile random-access memory (NVRAM), which retains data without applied power. They were also able to disable both BT and Wi-Fi on the device; and most concerningly, control the general-purpose input/output (GPIO) of the device if the attacker knows addresses to attached functions-controlling actuators. GPIO is used to communicate the ON/OFF signals received from connected switches, or the digital readings received from connected sensors, to the CPU.

“This has serious implications if such an attack is applied to Bluetooth-enabled smart home products,” the researchers warned.

Second form of atatck - Laptops and devices The second attack scenario can lead to DoS in laptops and smartphones. Researchers were able to achieve this using gear containing Intel AX200 SoCs and Qualcomm WCN3990 SoCs.

One of the DoS bugs (CVE-2021-34147) exists because of a failure in the SoC to free resources upon receiving an invalid LMP_timing_accuracy_response from a connected BT device (i.e., a “slave,” according to the paper:

“The attacker can exhaust the SoC by (a) paging, (b) sending the malformed packet, and (c) disconnecting without sending LMP_detach,” researchers wrote. “These steps are repeated with a different BT address (i.e., BDAddress) until the SoC is exhausted from accepting new connections. On exhaustion, the SoC fails to recover itself and disrupts current active connections, triggering firmware crashes sporadically.”

The researchers were able to forcibly disconnect slave BT devices from Windows and Linux laptops, and cause BT headset disruptions on Pocophone F1 and Oppo Reno 5G smartphones.

A third possible attack - Audio attacks A third attack scenario was discovered while probing various BT speakers (specifically the Mi Portable Bluetooth Speaker – MDZ-36-DB, BT Headphone and BT Audio Modules) and an unbranded BT audio receiver.

They all are variously subject to a series of bugs (CVE-2021-31609 andCVE-2021-31612, failures when sending oversized LMP packets; CVE-2021-31613, truncated packets; CVE-2021-31611, starting procedures out-of-order; and CVE-2021-28135, CVE-2021-28155 and CVE-2021-31717, feature response flooding).

Successful exploits can “freeze” devices, requiring the user to manually turn on unresponsive devices afterwards. For the Xiaomi MDZ-36-DBs and JBL TUNE 500BTs, this can be done while the user is actively playing music, researchers noted.

“Although issues were found in SoCs targeted to audio products, the BT implementation can be reused in a number of SoCs destined to different BT products,” they added.

These are just a few of the possible exploit scenarios.

In affected versions of Confluence Server and Data Center, an OGNL injection vulnerability exists that would allow an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data Center instance. The affected versions are before version 6.13.23, from version 6.14.0 before 7.4.11, from version 7.5.0 before 7.11.6, and from version 7.12.0 before 7.12.5.

CVE-2021-26084 Detail

The attack has been reported to have affected Jenkins. The developers of the Jenkins server, one of the most widely used open-source automation systems, said they suffered a security breach after hackers gained access to one of their internal servers built on Confluence and deployed a cryptocurrency miner.

The Jenkins breach is part of a recent wave of attacks exploiting CVE-2021-26084 (also nicknamed Confluenza), an authentication bypass and command injection bug in Atlassian’s Confluence server which is reported as an OGNL injection vulnerability that allows an unauthenticated attacker to execute arbitrary code on a Confluence Server or Data Center instance.

This vulnerability is being actively exploited in the wild. Affected servers should be patched immediately.

Atlassian workgroup discussion

The issue was discovered by Benny Jacob (SnowyOwl) via the Atlassian public bug bounty program.

It has been listed as a low priority at Atlassian despite it being reported to have a critical severity.