Category Archives: Linux

Linux kernel privilege escalation flaw CVE-2019-11815 affects RDS

Experts discovered a privilege escalation vulnerability in the Linux Kernel, tracked as CVE-2019-11815, that affects the implementation of RDS over TCP.

Experts discovered a memory corruption vulnerability in Linux Kernel that resides in the implementation of the Reliable Datagram Sockets (RDS) over TCP.

The vulnerability tracked as CVE-2019-11815 could lead to privilege escalation, it received a CVSS base score of 8.1. The vulnerability only affects Linux kernels prior to 5.0.8, that use the Reliable Datagram Sockets (RDS) for the TCP module.

“An issue was discovered in rds_tcp_kill_sock in net/rds/tcp.c in the Linux kernel before 5.0.8. There is a race condition leading to a use-after-free, related to net namespace cleanup.” reads the security advisory published by the NIST.

The NIST classified the flaw as a race condition that affects the kernel’s rds_tcp_kill_sock in net/rds/tcp.c.. 

The vulnerability could be exploited by a remote attacker with no privileges over the network, the issue doesn’t require user interaction.

An attacker could exploit the vulnerability to access restricted information or trigger a denial of service condition. 

“A system that has the rds_tcp kernel module loaded (either through autoload via local process running listen(), or manual loading) could possibly cause a use after free (UAF) in which an attacker who is able to manipulate socket state while a network namespace is being torn down,” reads the advisory published by Red Hat.

According to a note included in the security advisory published by Canonical, there is no evidence that the bug is remotely exploitable. 

“I haven’t yet seen evidence to support allegations that this is remotely exploitable. Blacklisting rds.ko module is probably sufficient to prevent the vulnerable code from loading.” said Seth Arnold from the Ubuntu’s security team. “The default configuration of the kmod package has included RDS in /etc/modprobe.d/blacklist-rare-network.conf since 14.04 LTS. I’m dropping priority as a result.”

Both Suse and Debian also published security advisories for the
CVE-2019-11815 vulnerability.

If you appreciate my effort in spreading cybersecurity awareness, please vote for Security Affairs in the section “Your Vote for the Best EU Security Tweeter”

Thank you

Pierluigi Paganini

(SecurityAffairs – Linux, CVE-2019-11815)

The post Linux kernel privilege escalation flaw CVE-2019-11815 affects RDS appeared first on Security Affairs.

Chronicle experts spotted a Linux variant of the Winnti backdoor

Security researchers from Chronicle, Alphabet’s cyber-security division, have spotted a Linux variant of the Winnti backdoor.

Security experts from Chronicle, the Alphabet’s cyber-security division, have discovered a Linux variant of the Winnti backdoor. It is the first time that researchers found a Linux version of the backdoor user by China-linked APT groups tacked as Winnti.

chinese hackers

The experts believe that under the Winnti umbrella there are several APT groups, including  Winnti, Gref, PlayfullDragon, APT17, DeputyDog, Axiom, BARIUM, LEADPassCV, Wicked Panda, and ShadowPad. The groups show similar tactics, techniques, and Procedures (TTPs) and in some cases shared portions of the same hacking infrastructure.

Chronicle researchers while investigating the cyber attack that hit the Bayer pharmaceutical company in April.

Searching for samples of Winnti malware on its VirusTotal platform, the experts discovered a Linux variant of Winnti, dating back to 2015. At the time the malware was used in the hack of a Vietnamese gaming company.

“In April 2019, reports emerged of an intrusion involving Winnti malware at a German Pharmaceutical company.” reads the analysis published by
Chronicle. “Analysis of these larger convoluted clusters is ongoing. While reviewing a 2015 report of a Winnti intrusion at a Vietnamese gaming company, we identified a small cluster of Winnti⁶ samples designed specifically for Linux.” 

The technical analysis of the Linux version of Winnti backdoor revealed the presence of two files, the main backdoor (libxselinux) and a library ( used to avoid the detection.

The Winnti backdoor has a modular structure, it implements distinct functionalities using plugins. During the analysis, the researchers were unable to recover any active plugins. Experts believe attackers used additional modules for Linux to implement plugins for remote command execution, file exfiltration, and socks5 proxying on the infected host.

Further analysis revealed many code similarities between the Linux version of the Winnti variant and the Winnti 2.0 Windows version.

“The decoded configuration is similar in structure to the version Kaspersky classifies as Winnti 2.0, as well as samples in the 2015 Novetta report.” continues the report. “Embedded in this sample’s configuration three command-and-control server addresses and two additional strings we believe to be campaign designators. Winnti ver. 1, these values were designated as ‘tag’ and ‘group’. “

Like Windows variants of the Winnti backdoor, the Linux version also handles outbound communications using multiple protocols including ICMP, HTTP, as well as custom TCP and UDP protocols.

The Linux version also implements another feature that allows threat actors to initiate connections to infected hosts without requiring a connection to a control server.

The feature could allow attackers to directly access infected systems when access to the hard-coded control servers is disrupted.

“This secondary communication channel may be used by operators when access to the hard-coded control servers is disrupted. Additionally, the operators could leverage this feature when infecting internet-facing devices in a targeted organization to allow them to reenter a network if evicted from internal hosts.” continues the report. “This passive implant approach to network persistence has been previously observed with threat actors like Project Sauron and the Lamberts.”

In 2016, the Winniti hackers also hit German heavy industry giant ThyssenKrupp to steal company secrets.

Technical information about the above feature was also shared by the Thyssenkrupp CERT, its experts released a Nmap script that could be used to identify Winnti infections through network scanning.

“An expansion into Linux tooling indicates iteration outside of their traditionalcomfort zone. This may indicate the OS requirements of their intended targets but it may also be an attempt to take advantage of a security telemitry blindspot in many enterprises, as is with Penquin Turla and APT28’s Linux XAgent variant.” concludes the report that includes IoCs and Yara rules for the identification of the threat.

If you appreciate my effort in spreading cybersecurity awareness, please vote for Security Affairs in the section “Your Vote for the Best EU Security Tweeter”

Thank you

Pierluigi Paganini

(SecurityAffairs – Winnti, Linux malware)

The post Chronicle experts spotted a Linux variant of the Winnti backdoor appeared first on Security Affairs.

Microsoft’s Attack Surface Analyzer now works on Macs and Linux, too

Microsoft has rewritten and open-sourced Attack Surface Analyzer (ASA), a security tool that points out potentially risky system changes introduced by the installation of new software or configuration changes. About Attack Surface Analyzer The initial version of the tool (v1.0, aka “classic”) was released in 2012 and worked only on Windows. It can be still downloaded, but is not supported any longer. This newest version (v.2.0) is built using .NET Core 2.1 and Electron, and … More

The post Microsoft’s Attack Surface Analyzer now works on Macs and Linux, too appeared first on Help Net Security.

CVE-2019-11815 Remote Code Execution affects Linux Kernel prior to 5.0.8

Security experts have found a race condition vulnerability (CVE-2019-11815) in Linux Kernel Prior to 5.0.8 that expose systems to remote code execution.

Linux systems based on kernel versions prior to 5.0.8 are affected by a race condition vulnerability leading to a use after free that could be exploited by hackers to get remote code execution.

Attackers can trigger the race condition issue that resides in the rds_tcp_kill_sock TCP/IP implementation in net/rds/tcp.c to cause a denial-of-service (DoS) condition and to execute code remotely on vulnerable Linux machines.

The vulnerability could be exploited by sending specially crafted TCP packets to vulnerable Linux systems.

The vulnerability tracked as CVE-2019-11815 received a CVSS v3.0 base score of 8.1, it could be abused by unauthenticated attackers without user interaction.

Anyway, the NIST assigned to the vulnerability an exploitability score of 2.2 and an impact score of 5.9 because it is difficult to exploit.

“An issue was discovered in rds_tcp_kill_sock in net/rds/tcp.c in the Linux kernel before 5.0.8. There is a race condition leading to a use-after-free, related to net namespace cleanup.” reads the description provided by Mitre.

The exploitation of the flaw could allow attackers to access resources, modify any files, and deny access to resources.

CVE-2019-11815 linux flaw

The development team of Linux kernel already released a security patch that addressed the CVE-2019-11815 flaw at the end of March. The vulnerability was completely fixed with the release of Linux kernel 5.0.8 version.

Below the security advisories published by the major Linux distributions:

Pierluigi Paganini

(SecurityAffairs – CVE-2019-11815, Linux Kernel)

The post CVE-2019-11815 Remote Code Execution affects Linux Kernel prior to 5.0.8 appeared first on Security Affairs.

Troubleshooting NSM Virtualization Problems with Linux and VirtualBox

I spent a chunk of the day troubleshooting a network security monitoring (NSM) problem. I thought I would share the problem and my investigation in the hopes that it might help others. The specifics are probably less important than the general approach.

It began with ja3. You may know ja3 as a set of Zeek scripts developed by the Salesforce engineering team to profile client and server TLS parameters.

I was reviewing Zeek logs captured by my Corelight appliance and by one of my lab sensors running Security Onion. I had coverage of the same endpoint in both sensors.

I noticed that the SO Zeek logs did not have ja3 hashes in the ssl.log entries. Both sensors did have ja3s hashes. My first thought was that SO was misconfigured somehow to not record ja3 hashes. I quickly dismissed that, because it made no sense. Besides, verifying that intution required me to start troubleshooting near the top of the software stack.

I decided to start at the bottom, or close to the bottom. I had a sinking suspicion that, for some reason, Zeek was only seeing traffic sent from remote systems, and not traffic originating from my network. That would account for the creation of ja3s hashes, for traffic sent by remote systems, but not ja3 hashes, as Zeek was not seeing traffic sent by local clients.

I was running SO in VirtualBox 6.0.4 on Ubuntu 18.04. I started sniffing TCP network traffic on the SO monitoring interface using Tcpdump. As I feared, it didn't look right. I ran a new capture with filters for ICMP and a remote IP address. On another system I tried pinging the remote IP address. Sure enough, I only saw ICMP echo replies, and no ICMP echoes. Oddly, I also saw doubles and triples of some of the ICMP echo replies. That worried me, because unpredictable behavior like that could indicate some sort of software problem.

My next step was to "get under" the VM guest and determine if the VM host could see traffic properly. I ran Tcpdump on the Ubuntu 18.04 host on the monitoring interface and repeated my ICMP tests. It saw everything properly. That meant I did not need to bother checking the switch span port that was feeding traffic to the VirtualBox system.

It seemed I had a problem somewhere between the VM host and guest. On the same VM host I was also running an instance of RockNSM. I ran my ICMP tests on the RockNSM VM and, sadly, I got the same one-sided traffic as seen on SO.

Now I was worried. If the problem had only been present in SO, then I could fix SO. If the problem is present in both SO and RockNSM, then the problem had to be with VirtualBox -- and I might not be able to fix it.

I reviewed my configurations in VirtualBox, ensuring that the "Promiscuous Mode" under the Advanced options was set to "Allow All". At this point I worried that there was a bug in VirtualBox. I did some Google searches and reviewed some forum posts, but I did not see anyone reporting issues with sniffing traffic inside VMs. Still, my use case might have been weird enough to not have been reported.

I decided to try a different approach. I wondered if running VirtualBox with elevated privileges might make a difference. I did not want to take ownership of my user VMs, so I decided to install a new VM and run it with elevated privileges.

Let me stop here to note that I am breaking one of the rules of troubleshooting. I'm introducing two new variables, when I should have introduced only one. I should have built a new VM but run it with the same user privileges with which I was running the existing VMs.

I decided to install a minimal edition of Ubuntu 9, with VirtualBox running via sudo. When I started the VM and sniffed traffic on the monitoring port, lo and behold, my ICMP tests revealed both sides of the traffic as I had hoped. Unfortunately, from this I erroneously concluded that running VirtualBox with elevated privileges was the answer to my problems.

I took ownership of the SO VM in my elevated VirtualBox session, started it, and performed my ICMP tests. Womp womp. Still broken.

I realized I needed to separate the two variables that I had entangled, so I stopped VirtualBox, and changed ownership of the Debian 9 VM to my user account. I then ran VirtualBox with user privileges, started the Debian 9 VM, and ran my ICMP tests. Success again! Apparently elevated privileges had nothing to do with my problem.

By now I was glad I had not posted anything to any user forums describing my problem and asking for help. There was something about the monitoring interface configurations in both SO and RockNSM that resulted in the inability to see both sides of traffic (and avoid weird doubles and triples).

I started my SO VM again and looked at the script that configured the interfaces. I commented out all the entries below the management interface as shown below.

$ cat /etc/network/interfaces

# This configuration was created by the Security Onion setup script.
# The original network interface configuration file was backed up to:
# /etc/network/interfaces.bak.
# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

# loopback network interface
auto lo
iface lo inet loopback

# Management network interface
auto enp0s3
iface enp0s3 inet static
  dns-domain localdomain

#auto enp0s8
#iface enp0s8 inet manual
#  up ip link set $IFACE promisc on arp off up
#  down ip link set $IFACE promisc off down
#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

#auto enp0s9
#iface enp0s9 inet manual
#  up ip link set $IFACE promisc on arp off up
#  down ip link set $IFACE promisc off down
#  post-up ethtool -G $IFACE rx 4096; for i in rx tx sg tso ufo gso gro lro; do ethtool -K $IFACE $i off; done
#  post-up echo 1 > /proc/sys/net/ipv6/conf/$IFACE/disable_ipv6

I rebooted the system and brought the enp0s8 interface up manually using this command:

$ sudo ip link set enp0s8 promisc on arp off up

Fingers crossed, I ran my ICMP sniffing tests, and voila, I saw what I needed -- traffic in both directions, without doubles or triples no less.

So, there appears to be some sort of problem with the way SO and RockNSM set parameters for their monitoring interfaces, at least as far as they interact with VirtualBox 6.0.4 on Ubuntu 18.04. You can see in the network script that SO disables a bunch of NIC options. I imagine one or more of them is the culprit, but I didn't have time to work through them individually.

I tried taking a look at the network script in RockNSM, but it runs CentOS, and I'll be darned if I can't figure out where to look. I'm sure it's there somewhere, but I didn't have the time to figure out where.

The moral of the story is that I should have immediately checked after installation that both SO and RockNSM were seeing both sides of the traffic I expected them to see. I had taken that for granted for many previous deployments, but something broke recently and I don't know exactly what. My workaround will hopefully hold for now, but I need to take a closer look at the NIC options because I may have introduced another fault.

A second moral is to be careful of changing two or more variables when troubleshooting. When you do that you might fix a problem, but not know what change fixed the issue.