Category Archives: Linux

50 Best Hacking & Forensics Tools Included in Kali Linux

50 Best Hacking & Forensics Tools Included in Kali Linux 50 Best Hacking & Forensics Tools Included in Kali Linux: Welcome to HackingVision, in this article we will list the best 50 hacking & forensics tools that are included in Kali Linux. Debian-based Linux distribution aimed at advanced Penetration Testing and Security Auditing. Kali contains ... Read more50 Best Hacking & Forensics Tools Included in Kali Linux

The post 50 Best Hacking & Forensics Tools Included in Kali Linux appeared first on HackingVision.

A critical Linux Wi-Fi bug could be exploited to fully compromise systems

A researcher discovered a critical Linux vulnerability, tracked as CVE-2019-17666, that could be exploited to fully compromise vulnerable machines.

Nico Waisman, principal security engineer at Github, discovered a critical Linux flaw, tracked as CVE-2019-17666, that could be exploited by attackers to fully compromise vulnerable machines.

The vulnerability affects Linux versions through 5.3.6, according to the researchers the issue exists at least since 2015.

The vulnerability is a heap buffer overflow issue that resides in the “rtlwifi” driver that allows certain Realtek Wi-Fi modules to communicate with the Linux operating system.

“rtl_p2p_noa_ie in drivers/net/wireless/realtek/rtlwifi/ps.c in the Linux kernel through 5.3.6 lacks a certain upper-bound check, leading to a buffer overflow.” reads the description published by NVD.

The issue affects a feature called the Notice of Absence protocol implemented in the “rtlwifi” driver. The protocol is used by devices to autonomously power down their radio and save energy.

“The Notice of Absence (NoA) protocol allows a P2P GO to announce time intervals, referred to as absence periods, where P2P Clients are not allowed to access the channel, regardless of whether they are in power save or in active mode. In this way, a P2P GO can autonomously decide to power down its radio to save energy.” reads a paper on Device to device communications.

The expert noticed that the driver fails to correctly handle Notice of Absence packets.

“Nicolas Waisman noticed that even though noa_len is checked for a compatible length it’s still possible to overrun the buffers of p2pinfo since there’s no check on the upper bound of noa_num. Bound noa_num against P2P_MAX_NOA_NUM.” reads the security advisory.

An attacker could use packets with incorrect length to trigger the flaw and cause the system to crash.

An unauthenticated attacker could trigger the flaw only if he is within the radio range of the target device.

“The vulnerability triggers an overflow, which means it could make Linux crash or if a proper exploit is written (which is not trivial), an attacker could obtain remote code-execution,” Waisman explained to the Threatpost.

The Linux kernel team has already developed a fix that is currently under revision, it has not yet been included into the Linux kernel.

Pierluigi Paganini

(SecurityAffairs – Linux Kernel, hacking)

The post A critical Linux Wi-Fi bug could be exploited to fully compromise systems appeared first on Security Affairs.

sudo flaw allows any users to run commands as Root on Linux

Experts discovered a security policy bypass issue in the Sudo utility that is installed as a command on almost every Linux and Unix system.

The Sudo utility that is installed as a command on almost every Linux and Unix system is affected by a security policy bypass issue tracked as CVE-2019-14287.

The vulnerability could be exploited by an ill-intentioned user or a malicious program to execute arbitrary commands as root on a targeted Linux system, even if the “sudoers configuration” disallows the root access.

sudo is a program for Unix-like computer operating systems that allows users to run programs with the security privileges of another user, by default the superuser. It originally stood for “superuser do” as the older versions of sudo were designed to run commands only as the superuser.

“When sudo is configured to allow a user to run commands as an arbitrary user via the ALL keyword in a Runas specification, it is possible to run commands as root by specifying the user ID -1 or 4294967295.” reads the security advisory.

“This can be used by a user with sufficient sudo privileges to run commands as root even if the Runas specification explicitly disallows root access as long as the ALL keyword is listed first in the Runas specification.

Log entries for commands run this way will list the target user as 4294967295 instead of root. In addition, PAM session modules will not be run for the command.”

Unlike the su command, users must, by default, supply their password for authentication, rather than the password of the target user. Once authenticated, and if the configuration file (/etc/sudoers) permits the user access, the system will invoke the requested command. 

Administrators can configure a sudoers file to define which users are allowed to run a list of commands as to specific users.

Now, due to the CVE-2019-14287 flaw, even is a user is not allowed to run a specific command as root it is possible to bypass the restriction

An attacker could exploit the vulnerability to run commands as root just by specifying the user ID “-1” or “4294967295.” This is possible because the function that converts user id into its username incorrectly handles the ‘-1’ value, or its unsigned equivalent 4294967295, and interprets it as 0, which is always associated with user ID of root user.

“Fixed CVE-2019-14287, a bug where a sudo user may be able to + run a command as root when the Runas specification explicitly + disallows root access as long as the ALL keyword is listed first.” states the advisory.

So, even if a user has been restricted to run a specific, or any, command as root, the vulnerability could allow the user to bypass this security policy and completely take over the system.

“Exploiting the bug requires that the user have sudo privileges that allow them to run commands with an arbitrary user ID. Typically, this means that the user’s sudoers entry has the special value ALL in the Runas specifier.” continues the advisory.

“Additionally, because the user ID specified via the -u option does not exist in the password database, no PAM session modules will be run.”

“Additionally, because the user ID specified via the -u option does not exist in the password database, no PAM session modules will be run.

If a sudoers entry is written to allow the user to run a command as any user except root, the bug can be used to avoid this restriction. For example, given the following sudoers entry:”

    myhost bob = (ALL, !root) /usr/bin/vi

User bob is allowed to run vi as any user but root. However, due to the bug, bob is actually able to run vi as root by running sudo -u#-1 vi, violating the security policy.”

The CVE-2019-14287 vulnerability was discovered by Joe Vennix of Apple Information Security, it affects Sudo versions prior to 1.8.28.

Linux users urge to update sudo package to the latest version as soon as it is available.

Pierluigi Paganini

(SecurityAffairs – Linux, Sudo)

The post sudo flaw allows any users to run commands as Root on Linux appeared first on Security Affairs.

UNIX Co-Founder Ken Thompson’s BSD Password Has Finally Been Cracked

A 39-year-old password of Ken Thompson, the co-creator of the UNIX operating system among, has finally been cracked that belongs to a BSD-based system, one of the original versions of UNIX, which was back then used by various computer science pioneers. In 2014, developer Leah Neukirchen spotted an interesting "/etc/passwd" file in a publicly available source tree of historian BSD version 3,

Guess what? You should patch Exim again!

Hot on the heels of a patch for a critical RCE Exim flaw comes another one that fixes a denial of service (DoS) condition (CVE-2019-16928) that could also be exploited by attackers to pull off remote code execution. With no mitigations available at this time, Exim maintainers urge admins to upgrade to version 4.92.3, which has been released on Sunday. About Exim and the flaw (CVE-2019-16928) According to E-Soft, Exim is the most widely used … More

The post Guess what? You should patch Exim again! appeared first on Help Net Security.

Skidmap Linux miner leverages kernel-mode rootkits to evade detection

Trend Micro researchers spotted a piece of Linux cryptocurrency miner, dubbed Skidmap that leverages kernel-mode rootkits to evade the detection.

Skidmap is a new piece of crypto-miner detected by Trend Micro that target Linux machines, it uses kernel-mode rootkits to evade the detection.

This malware outstands similar miners because of the way it loads malicious kernel modules to evade the detection.

The crypto-miner set up a secret master password that uses to access any user account on the system.

“These kernel-mode rootkits are not only more difficult to detect compared to its user-mode counterparts — attackers can also use them to gain unfettered access to the affected system. A case in point: the way Skidmap can also set up a secret master password that gives it access to any user account in the system.” states the analysis published by TrendMicro. “Conversely, given that many of Skidmap’s routines require root access, the attack vector that Skidmap uses — whether through exploits, misconfigurations, or exposure to the internet — are most likely the same ones that provide the attacker root or administrative access to the system.”

Experts noticed that several routines implemented by Skidmap require root access, suggesting that its attack vector is the same that provided the attackers with root or administrative access to the system.

The infection chain sees the Skidmap miner installing itself via crontab, then the malicious code downloads and executes the main binary. The malware decreases the security settings of the target systems by configuring the Security-Enhanced Linux (SELinux) module to the permissive mode or by disabling the SELinux policy and setting selected processes to run in confined domains. The miner also set up backdoor access to the infected system.

Skidmap also provides attackers with backdoor access to the infected machine.

Skidmap also sets up a way to gain backdoor access to the machine. It does this by having the binary add the public key of its handlers to the authorized_keys file, which contains keys needed for authentication.” continues the report.

“Besides the backdoor access, Skidmap also creates another way for its operators to gain access to the machine. The malware replaces the system’s pam_unix.so file (the module responsible for standard Unix authentication) with its own malicious version”

The main binary checks whether the system runs on Debian or RHEL/CentOS, then drops the miner and other for the specific Linux distro.

Trend Micro experts revealed that the Skidmap miner has notable components designed to obfuscate its activities and ensure that they continue to run. Samples of these components are:

A fake “” binary that replaces the original, once executed it will randomly set up a malicious cron job to download and execute a file.

Another component is “kaudited,” s file installed as /usr/bin/kaudited that drops and installs several loadable kernel modules (LKMs). The kaudited binary also drops a watchdog component used to monitor the mining process.

Trend Micro also described the “iproute” module that hooks the system call getdents that is normally used to read the contents of a directory, with the intent of hiding specific files.

The last component is “netlink,” a rootkit that can fake the network traffic statistics and CPU-related statistics to hide the activity of the malware.

Skidmap uses fairly advanced methods to ensure that it and its components remain undetected. For instance, its use of LKM rootkits — given their capability to overwrite or modify parts of the kernel — makes it harder to clean compared to other malware.” Trend Micro concludes. “In addition, Skidmap has multiple ways to access affected machines, which allow it to reinfect systems that have been restored or cleaned up,”

Pierluigi Paganini

(SecurityAffairs – Skidmap miner, Linux)

The post Skidmap Linux miner leverages kernel-mode rootkits to evade detection 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
  address 192.168.40.76
  gateway 192.168.40.1
  netmask 255.255.255.0
  dns-nameservers 192.168.40.1
  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.