OMIGOD Flaw in Azure on Linux Persists Despite Microsoft Fixes

- Posted in Uncategorized by

Cybercriminals are targeting Linux-based servers running Microsoft’s Azure public cloud environment that are vulnerable to flaws after Microsoft didn’t automatically apply a patch on affected clients in its infrastructure.

Recorded Future reports that the attacks began the night of Sept. 16 after a exploit proof-of-concept was published on GitHub. It was noted that about 10 malicious bot servers have been searching the internet for vulnerable systems. In addition, Cado Security researchers in a blog post also noted a tweet from cybersecurity researcher German Fernandez, who found that the infamous DDoS Mirai botnet – known for taking advantage of insecure Internet of Things (IoT) devices – also is exploiting OMIGOD.

The flaws include CVE-2021-38647, which is a remote code execution bug, and three privileged escalation vulnerabilities: CVE-2021-8648, CVE-2021-38645 and CVE-2021-38649. Ohfeld wrote that the researchers offered a conservative estimate that thousands of Azure customers and millions of endpoints are impacted by the flaws.

“Supply chain cyber attacks have disrupted everyday life and dominated headlines this year,” he wrote. “One of the biggest challenges in preventing them is that our digital supply chain is not transparent. If you don’t know what’s hidden in the services and products you use every day, how can you manage the risk?”

OMIGOD Microsoft

Microsoft was quick to issue fixes to the four vulnerabilities in its September release of security updates, and the vulnerabilities put a spotlight on the risk to supply chains that Microsoft open-source code represents, particularly for organizations using cloud computing services since Microsoft let go its Beta testing teams and community Beta testers that used to volunteer their time.

With OMIGOD, the issue relates to the app called Open Management Infrastructure (OMI), which is embedded in many Azure services and is sponsored by Microsoft open-source OMI project in collaboration with The Open Group.

When users enable any of these popular services, OMI is silently installed on their Virtual Machine by Azure, running at the highest privileges possible. This happens without customers’ explicit consent or knowledge. Users simply click agree to log collection during setup and they have unknowingly opted in to the Microsoft application. Because Azure provides virtually no public documentation about OMI, most customers have never heard of it and are unaware that this attack surface exists in their environment.

The OMI agent operates as root (the highest privileges any users can have) and with it using a Unix socket or through an HTTP API has unlimited control. In Linux, and Unix based environments, the use of Root for any application is discouraged, and this should be the Microsoft default as well, especially when the app is exposed to internet access, but it is not the case as OMI shows. With OMI being so poorly implemented bad actors can easily gain control of the servers.

“This vulnerability can be also used by attackers to obtain initial access to a target Azure environment and then move laterally within it,” Ohfeld wrote in a technical blog. Thus, an exposed port with such access privilege's is a holy grail for malicious attackers, and with OMI, one simple exploit provides attackers with access to new targets, execute commands at the highest privileges, and possibly spread exponentially to new target machines.

Recorded Future noted that Microsoft addressed the bug by developing version 1.6.8.1 of the OMI client and releasing it on GitHub, but didn’t automatically install the update on OMI clients in its infrastructure, essentially leaving tens of thousands of servers vulnerable. The company also took three days to replace the OMI client version inside its available Azure Linux VM images.

The cybersecurity firm said a query on the Shodan search engine found more than 15,600 Azure Linux servers connected to the internet, all with possible exposure, and these are just the ones known.

Recommendations

  1. Immediately implementing the OMI patch.
  2. Remove it if it is unneeded
  3. Check and confirm all applications exposed to the internet
  4. Scan and check all server files, access controls, ports and privilege's as well as check your user accounts and groups.

"BadAlloc" RTOS Integer overflow vulnerability

- Posted in Vulnerability by

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

HAProxy Integer overflow exploit

- Posted in Vulnerability by

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.

HA Proxy exploit

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.

Office 365/2019 MSHTML Vulnerability

- Posted in Vulnerability by

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 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.