OMIGOD, an exploitable flaw in Microsoft’s open source code! – Bare security

Microsoft’s September 2021 Patch Tuesday updates were released this week.

The fix everyone was looking forward to was the patch for CVE-2021-40444, a zero-day remote code execution bug in MSHTML that was announced by Microsoft just days before the release of Patch Tuesday:

Remote bugs in MSHTML, which is the web rendering engine used by Internet Explorer (IE), are always a big deal, especially if crooks find them before the good guys do.

With so little time until Patch Tuesday, Microsoft’s big question was, “Are they going to get there?” “… and luckily the answer was” Yes “:

Of course, most Patch Tuesday updates close more than one security hole, and some of the others often don’t get much publicity either because they were found by the Good Guys first, which makes the patch proactive, either because they don’t. affect all computers on your network.

OMIGOD, there is also a Linux based bug

This month, CVE-2021-38647 turns out to be one such security hole – interesting and important, but apparently not very exciting.

This flaw does not directly affect Windows at all, as it is a bug in Microsoft’s open source Open Management Infrastructure (OMI) tool designed for Linux in general and for Linux servers hosted on Azure in particular.

You read that right: One of this month’s Patch Tuesday bug notifications was a flaw in a product, aimed at Linux sysadmins, that Microsoft ships as source code through its GitHub service.

This is because the relevant bugfixes were officially available in the OMI source code on August 12, 2021, over a month ago.

So this vulnerability appeared, on the surface, to be one that wasn’t really worth skipping, and which was probably already fixed on many or most servers, given that its public source code had been updated for a long time.

Well, Ace, the curiously named startup that discovered and reported this bug, and was therefore responsible for starting the patching process, thinks it’s definitely worth getting excited about.

In fact, they’re so excited about it that they’ve dubbed him OMIGOD, and wrote it on their corporate blog.

They even gave it a logo, which we used in the image at the top of the article.

It’s easy to be cynical when you hear the announcement of a new BWAIN – our lightweight acronym for Bug with awesome name – but if you have linux servers, it’s worth noting what Wiz has to say.

The bug in brief

Heavily simplified, OMI is Microsoft’s Linux answer to WMI, the Windows management interface that system administrators use to keep tabs on their Windows networks.

Like WMI, OMI code runs as a privileged process on your servers so that system administrators and system administration software can query and control what is happening, such as enumerating processes, launching utility programs, and verification of system configuration parameters.

Unfortunately, cyber crooks, especially ransomware criminals, love WMI as much as system administrators.

This is because WMI helps attackers plan and execute their destructive attacks across an entire organization, once they have an administrator level bridgehead somewhere on the network.

Unfortunately, OMIGOD is an IMO bug that, in theory, gives criminals the same kind of distributed power over your Linux servers …

… except you don’t need this administrator-level bridgehead first, as CVE-2021-38647 essentially provides a bridgehead of its own, allowing you to come in, take root, and take control. relay, all at once.

No password required

Surprisingly, the bug seems to come down to one ridiculously easy trick.

Rather than guessing a valid auth token to insert into a fraudulent OMI web request, you simply omit any mention of the auth token and voila!

Of course, with the relevant code fixes released over a month ago, in source code form nothing less, you can assume that Linux system administrators who are OMI users have already had ample time to to correct.

You can also assume that anyone relying on their Linux distribution to deliver updated binary packages (thus avoiding the need to rebuild code manually from source) would also be ahead of the game.

However, as Wiz quite accurately points out in his blog post, many Linux-on-Azure users may not know they have OMI, and therefore not even know how to check for security issues with it. .

This is because the OMI software may have been installed automatically, along with various Azure services that they have chosen to use.

Wiz claims that:

Azure customers on Linux machines – which represent more than half of all Azure instances according to Microsoft – are at risk if they use any of the following services / tools: Azure Automation, Azure Automatic Update, Azure Operations Management Suite ( OMS), Azure Log Analytics, Azure Configuration Management, Azure Diagnostics [and] Azure Container Insights,

As the company is forced to admit, “this is only a partial list”, limiting itself to those it knows, so there may be others.

If you are dealing with Linux servers, and especially if they are hosted on Azure, we suggest you check if you have OMI, and if so, make sure you have the latest version.

What to do?

  • 1. If you know you have IMO on your servers, make sure it is up to date. According to Microsoft, you can use the omicli ei (enumerate instance) to verify which version is installed on each server. Find a version 1.6.8-1 or later.
  • 2. If you are not sure whether you have installed OMI, search for it. You can search your file system for files called omilci.conf, omigen.conf and omiserver.conf, as well as files called .omiclirc and .omigenrc in the home directory of any account, or use your Linux distribution’s package manager to find packages with names beginning omi*. If you find OMI where you weren’t expecting it, GOTO 1.
  • 3. Check for listening network services that might be exposing OMI remotely. According to Wiz, the default port number is 5986 and remote access is not enabled by default. You can check the listening sockets on a server by using the netstat order. (See below.) Turn off remote access unless you want or really need it.
  • 4. Read Microsoft’s security tips for CVE-2021-38647. Note that there are three other, somewhat less severe vulnerabilities in OMI that Wiz found at the same time, so you can also read them: CVE-2021-38645, CVE-2021-38648 and CVE-2021-38649.

How to use the netstat order

To display all listening sockets (root required):

# netstat -l
[...]

To display all listening sockets with IDs and process names:

# netstat -lp  
[...]

Restrict output to listening TCP sockets, since OMI uses HTTPS over TCP:

# netstat -lp | grep tcp
[...]

To practice using this command, start a listening TCP socket in a terminal window, like this …

$ nc -n -l -v -p 8888 
listening on [any] 8888 ...

… then, in another terminal window, use netstat to find the listening socket on port 8888:

# netstat -lp | grep tcp
tcp    0   0  [0.0.0.0]:8888   0.0.0.0:*     LISTEN      {PROCESSNO]/nc

Note that in the aov example, [0.0.0.0]:8888 indicates that the nc process is listening on port 8888 on all network interfaces, which means that the port can be accessed locally or remotely.



Source link

Leave a reply