Archive

Archive for the ‘Linux’ Category

Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices

May 19th, 2022 No comments

In the last six months, we observed a 254% increase in activity from a Linux trojan called XorDdos. First discovered in 2014 by the research group MalwareMustDie, XorDdos was named after its denial-of-service-related activities on Linux endpoints and servers as well as its usage of XOR-based encryption for its communications.

XorDdos depicts the trend of malware increasingly targeting Linux-based operating systems, which are commonly deployed on cloud infrastructures and Internet of Things (IoT) devices. By compromising IoT and other internet-connected devices, XorDdos amasses botnets that can be used to carry out distributed denial-of-service (DDoS) attacks. Using a botnet to perform DDoS attacks can potentially create significant disruptions, such as the 2.4 Tbps DDoS attack Microsoft mitigated in August 2021. DDoS attacks in and of themselves can be highly problematic for numerous reasons, but such attacks can also be used as cover to hide further malicious activities, like deploying malware and infiltrating target systems.

Botnets can also be used to compromise other devices, and XorDdos is known for using Secure Shell (SSH) brute force attacks to gain remote control on target devices. SSH is one of the most common protocols in IT infrastructures and enables encrypted communications over insecure networks for remote system administration purposes, making it an attractive vector for attackers. Once XorDdos identifies valid SSH credentials, it uses root privileges to run a script that downloads and installs XorDdos on the target device.

XorDdos uses evasion and persistence mechanisms that allow its operations to remain robust and stealthy. Its evasion capabilities include obfuscating the malware’s activities, evading rule-based detection mechanisms and hash-based malicious file lookup, as well as using anti-forensic techniques to break process tree-based analysis. We observed in recent campaigns that XorDdos hides malicious activities from analysis by overwriting sensitive files with a null byte. It also includes various persistence mechanisms to support different Linux distributions. 

Figure 1. A typical attack vector for XorDdos malware

XorDdos may further illustrate another trend observed in various platforms, in which malware is used to deliver other dangerous threats. We found that devices first infected with XorDdos were later infected with additional malware such as the Tsunami backdoor, which further deploys the XMRig coin miner. While we did not observe XorDdos directly installing and distributing secondary payloads like Tsunami, it’s possible that the trojan is leveraged as a vector for follow-on activities.

Microsoft Defender for Endpoint protects against XorDdos by detecting and remediating the trojan’s multi-stage, modular attacks throughout its entire attack chain and any potential follow-on activities on endpoints. In this blog post, we detail our in-depth analysis of XorDdos to help defenders understand its techniques and protect their networks from this stealthy malware.

This blog post covers the following topics:

Initial access

XorDdos propagates primarily via SSH brute force. It uses a malicious shell script to try various root credential combinations across thousands of servers until finding a match on a target Linux device. As a result, we see many failed sign-in attempts on devices successfully infected by the malware:

Figure 2's line chart depicts the increasing amount of failed sign-in attempts by a device infected by XorDdos.
Figure 2. Failed sign-in attempts on a device affected by XorDdos

Our analysis determined two of XorDdos’ methods for initial access. The first method involves copying a malicious ELF file to temporary file storage /dev/shm and then running it. Files written at /dev/shm are deleted during system restart, thus concealing the source of infection during forensic analysis.

The second method involves running a bash script that performs the following activities via the command line:

  1. Iterates the following folders to find a writable directory:
    • /bin
    • /home
    • /root
    • /tmp
    • /usr
    • /etc
  2. If a writable directory is found, changes the working directory to the discovered writable directory.
  3. Uses the curl command to download the ELF file payload from the remote location hxxp://Ipv4PII_777789ffaa5b68638cdaea8ecfa10b24b326ed7d/1[.]txt and saves the file as  ygljglkjgfg0.
  4. Changes the file mode to “executable”.
  5. Runs the ELF file payload.
  6. Moves and renames the Wget binary to evade rule-based detections triggered by malicious usage of the Wget binary. In this case, it renames the Wget binary to good and moves the file to the following locations:
    • mv /usr/bin/wget /usr/bin/good
    • mv /bin/wget /bin/good
  7. Attempts to download the ELF file payload for a second time, now only using the file good and not the Wget binary.
  8. After running the ELF file, uses an anti-forensic technique that hides its past activity by overwriting the content of the following sensitive files with a newline character:
Sensitive File Description
/root/.bash_history Contains the commands that were run earlier
/var/log/wtmp Contains login related record for users
/var/log/btmp Contains record of failed login attempt
/var/log/lastlog Contains the recent login information for users
/var/log/secure Contains information related to security such as logs for authentication failure, sudo logins, and authorization privileges
/var/log/boot.log Contains information related to system boot and message logged via system startup processes
/var/log/cron Contains information related to cron job launch, success and failure error logs
/var/log/dmesg Contains information related to kernel ring buffer messages, hardware devices, drivers, etc.
/var/log/firewalld Contains logs related to firewall activities
/var/log/maillog Contains information related to a mail server running on the system
/var/log/messages Contains generic system activity messages
/var/log/spooler Contains messages from usenet
/var/log/syslog Contains generic system activity messages
/var/log/yum.log Contains the package logs related to installation\remove\update activities done via yum utility
Figure 3 displays the remote bash script command used for initial access
Figure 3. Remote bash script command used for initial access

Whichever initial access method is used, the result is the same: the running of a malicious ELF file, which is the XorDdos malware. In the next section, we do a deep dive into the XorDdos payload.

XorDdos payload analysis

The XorDdos payload we analyzed for this research is a 32-bit ELF file that was not stripped, meaning it contained debug symbols that detailed the malware’s dedicated code for each of its activities. The inclusion of debug symbols makes it easier to debug and reverse engineer non-stripped binaries, as compared to stripped binaries that discard these symbols. In this case, the non-stripped binary includes the following source-code file names associated with the symbol table entries as part of the .strtab section in the ELF file:

  • crtstuff.c
  • autorun.c
  • crc32.c
  • encrypt.c
  • execpacket.c
  • buildnet.c
  • hide.c
  • http.c
  • kill.c
  • main.c
  • proc.c
  • socket.c
  • tcp.c
  • thread.c
  • findip.c
  • dns.c

The above list of source-code file names indicate that the binary is programmed in C/C++ and that its code is modular.

Detection evasion capabilities

XorDdos contains modules with specific functionalities to evade detection, as detailed below.

Daemon processes

A daemon process is a process that runs in the background rather than under the control of users and detaches itself from the controlling terminal, terminating only when the system is shut down. Similar to some Linux malware families, the XorDdos trojan uses daemon processes, as detailed below, to break process tree-based analysis:

  1. The malware calls the subroutine daemon(__nochdir, __noclose) to set itself as a background daemon process, which internally calls fork() and setsid(). The fork() API creates a new child process with the same process group-id as the calling process.
  2. After the successful call to the fork() API, the parent stops itself by returning “EXIT_SUCCESS (0)”. The purpose is to ensure that the child process is not a group process leader, which is a prerequisite for the setsid() API call to be successful. It then calls setsid() to detach itself from the controlling terminal.
  3. The daemon subroutine also has a provision to change the directory to the root directory (“/“) if the first parameter __nochdir is called with a value equal to “0”. One reason for the daemon process to change the directory to the root partition (“/“)is because running the process from the mounted file system prevents unmounting unless the process is stopped.  
  4. It passes the second parameter __noclose as “0” to redirect standard input, standard output, and standard error to /dev/null. It does this by calling dup2 on the file descriptor for /dev/null.
  5. The malware calls multiple signal APIs to ignore a possible signal from the controlling terminal and detach the current process from the standard stream and HangUp signals (SIGHUP) when the terminal session is disconnected. Performing this evasive signal suppression helps stop the effects of standard libraries trying to write to standard output or standard error, or trying to read from standard input, which could stop the malware’s child process. The API signal() sets the disposition of the signal signum to the handler, which is either SIG_IGN, SIG_DFL, or the address of a programmer-defined signal handler. In this case, the second parameter is set to “SIG_IGN=1”, which ignores the signal corresponding to signum.
Figure 4 displays how signals associated with terminal-related operations are ignored.
Figure 4. Ignore signals associated with the terminal-related operations

XOR-based encryption

As its name suggests, XorDdos uses XOR-based encryption to obfuscate data. It calls the dec_conf function to decode encoded strings using the XOR key “BB2FA36AAA9541F0”. The table below shows the decoded values of the obfuscated data used across the malware’s various modules to conduct its activities.

Encrypted strings Decoded value
m7A4nQ_/nA /usr/bin/
m [(n3 /bin/
m6_6n3 /tmp/
m4S4nAC/n&ZV\x1aA/TB /var/run/gcc.pid
m.[$n__#4%\C\x1aB]0 /lib/libudev.so
m.[$n3 /lib/
m4S4nAC/nA /var/run/
!#Ff3VE.-7\x17V[_ cat resolv.conf
<Encrypted_Remote_URL> hxxp://aa.hostasa[.]org/config.rar

Process name spoofing

When a process is launched, arguments are provided to its main function as null-terminated strings, where the first argument is always the process image path. To spoof its process name, XorDdos zeroes out all argument buffers while running and overrides its first argument buffer containing the image path with a fake command line, such as cat resolv.conf.

Figure 5 displays how process name spoofing is achieved by modifying memory associated with argument vectors.
Figure 5. Process name spoofing achieved by modifying memory associated with argument vectors.
Figure 6 displays the output of the 'ps -aef' containing an entry for "cat resolv.conf".
Figure 6. Output of the ‘ps -aef’ contains an entry for “cat resolv.conf”

Kernel rootkit

Some XorDdos samples install a kernel rootkit. A rootkit is a kernel module that hides the presence of malicious code by modifying operating systems data structures. The XorDdos kernel rootkit generally has following capabilities:

  • Provide root access
  • Hide the kernel module
  • Hide the malware’s processes
  • Hide the malware’s network connections and ports

Based on the debug symbols found in the rootkit, it’s likely that XorDdos’ rootkit code was inspired by an open-source project called rooty. The following table describes the symbols found in the rootkit and their corresponding functionalities:

Function name   Description  
give_root   Provides a root privilege by setting a new set of credentials and assigning its UID, GID to “0”
module_hide Hides the rootkit kernel module
module_show Unhides the rootkit kernel module
get_udp_seq_show Hides the UDP4 connection by hooking /proc/net/udpHides the UDP6 connection by hooking /proc/net/udp6
get_tcp_seq_show Hides the TCP4 connection by hooking /proc/net/tcpHides the TCP6 connection by hooking /proc/net/tcp6
hide_udp4_port Adds a provided port to a list of hidden UDP4 ports
unhide_udp4_port Deletes a provided port from a list of hidden UDP4 ports
hide_udp6_port Adds a provided port to a list of hidden UDP6 ports
unhide_udp6_port Deletes a provided port from a list of hidden UDP6 ports
hide_tcp4_port Adds a provided port to a list of hidden TCP4 ports
unhide_tcp4_port Deletes a provided port from a list of hidden TCP4 ports
hide_tcp6_port Adds a provided port to a list of hidden TCP6 ports
unhide_tcp6_port Deletes a provided port from a list of hidden TCP6 ports
unhide_allz Iterates list of all hidden ports and deletes all entries

Process and port hiding

The malware tries to hide its processes and ports using its kernel rootkit component. Hiding a process assists the malware in evading rule-based detections.

The /proc filesystem contains information related to all running processes. A user-mode process can get any process specific information by reading the /proc directory that contains the subdirectory for each running process on the system, such as:

  • /proc/7728 – Contains process-id (PID) 7728-related information
  • /proc/698 – Contains PID 698-related information

Running the strace -e open ps command checks the traces of the open call on /proc/$pid to fetch information on running processes as part of the ps command.

> strace -e open ps
open(“/proc/3922/status”, O_RDONLY)     = 6
open(“/proc/4324/stat”, O_RDONLY)       = 6
open(“/proc/4324/status”, O_RDONLY)     = 6
open(“/proc/5559/stat”, O_RDONLY)       = 6
open(“/proc/5559/status”, O_RDONLY)     = 6
open(“/proc/5960/stat”, O_RDONLY)       = 6
open(“/proc/5960/status”, O_RDONLY)     = 6
open(“/proc/5978/stat”, O_RDONLY)       = 6
open(“/proc/5978/status”, O_RDONLY)     = 6

If the malware hides the $pid specific directory, it can conceal fetching the corresponding process from a user mode.

In this case, the malware has a provision for communicating with its rootkit component /proc/rs_dev by sending input and output control (IOCTL) calls with additional information to take appropriate action. IOCTL is one way to communicate between the user-mode service and kernel device driver. The malware uses the number “0x9748712” to uniquely identify its IOCTL calls from other IOCTL calls in the system.

Along with this number, it also passes an integer array. The first entry in the array corresponds to the command, and the second entry stores the value to act on, such as $pid.

Command Usage
0 Check if its rootkit driver is present
1, 2 Hide or unhide <PID>
3 Hide <port>

Persistence mechanisms

XorDdos uses various persistence mechanisms to support different Linux distributions when automatically launching upon system startup, as detailed below.

Init script

The malware drops an init script at the location /etc/init.d. Init scripts are startup scripts used to run any program when the system starts up. They follow the Linux Standard Base (LSB)-style header section to include default runlevels, descriptions, and dependencies.

Figure 7 displays the content of the init script dropped at the location /etc/init.d/HFLgGwYfSC.elf.
Figure 7. Content of the init script dropped at the location /etc/init.d/HFLgGwYfSC.elf

Cron script

The malware creates a cron script at the location /etc/cron.hourly/gcc.sh.The cron script passes parameters with the following content:

Figure 8 displays the contents of the gcc.sh script.
Figure 8. Content of the gcc.sh script

It then creates a /etc/crontab file to run /etc/cron.hourly/gcc.sh every three minutes:

Figure 9 displays the system command to delete the /etc/cron.hourly/gcc.sh entry from /etc/crontab file and add a new entry. It reads "system("sed -i \'/\\/etc\\/cron.hourly\\/gcc.sh/d\' /etc/crontab && echo \'*/3 * * * * root /etc/cron.hourly/gcc.sh\' >> /etc/crontab");
Figure 9. System command to delete the /etc/cron.hourly/gcc.sh entry from the /etc/crontab file and add a new entry
Figure 10 reads :*/3 * * * * root /etc/cron.hourly/gcc.sh"
Figure 10. The content of the file /etc/crontab

System V runlevel

A runlevel is a mode of init and the system that specifies what system services are operating for Unix System V-Style operating systems. Runlevels contain a value, typically numbered zero through six, which each designate a different system configuration and allows access to a different combination of processes. Some system administrators set a system’s default runlevel according to their needs or use runlevels to identify which subsystems are working, such as whether the network is operational. The /etc/rc<run_level> directory contains symbolic links (symlinks), which are soft links that point to the original file. These symlinks point to the scripts that should run at the specified runlevel.

The malware creates a symlink for the init script dropped at the location /etc/init.d/<base_file_name> with the directories associated with runlevels 1 through 5 at /etc/rc<run_level>.d/S90<base_file_name> and /etc/rc.d/rc<run_level>.d/S90<base_file_name>.

Figure 11 displays the installation of rc.d directory's symlink scripts with /etc/init.d/<base_file_name>.
Figure 11. Installation of rc.d directory’s symlink scripts with /etc/init.d/<base_file_name>

Auto-start services

The malware runs a command to install startup services that automatically run XorDdos at boot. The malware’s LinuxExec_Argv2 subroutine runs the system API with the provided arguments.

The commands chkconfig –add <service_name> and update-rc.d then add a service that starts the daemon process at boot.

Figure 12 displays chkconfig and update-rc.d commands installing the startup service
Figure 12. chkconfig and update-rc.d commands install the startup service

Argument-based code-flow

XorDdos has specific code paths corresponding to the number of arguments provided to the program. This flexibility makes its operation more robust and stealthy. The malware first runs without any argument and then later runs another instance with different arguments, such as PIDs and fake commands, to perform capabilities like clean-up, spoofing, and persistence.

Before handling the argument-based control, it calls the readlink API with the first parameter as /proc/self/exe to fetch its full process path. The full path is used later to create auto-start service entries and read the file’s content.

In this section, we will cover the main tasks carried out as part of the different arguments provided:

1: Standard code path without any provided arguments

This code path depicts the malware’s standard workflow, which is also the typical workflow where XorDdos runs as part of the entries created in system start-up locations.

The malware first checks whether it’s running from the locations /usr/bin/, /bin/, or /tmp/. If it’s not running from these locations, then it creates and copies itself using a 10-character string name on those locations, as well as /lib/ and /var/run/.

It also creates a copy of itself at the location /lib/libudev.so. To evade hash-based malicious file lookup, it performs the following steps, which modify the file hash to make every file unique:

  • Opens the file for writing only
  • Calls lseek (fd, 0, SEEK_END) to point at the last position in the file
  • Creates a random 10-character string
  • Writes the string at the end of the file with an additional null byte

After modifying the file, it runs the binary, performs a double fork(), and deletes its file from the disk.

Figure 13 displays the end of the malware file containing two random strings, ‘wieegnexuk’ and ‘yybrdajydg,’ indicating that the original malware binary was modified twice
Figure 13. The end of the malware file contains two random strings, ‘wieegnexuk’ and ‘yybrdajydg,’ indicating that the original malware binary was modified twice

2: Clean-up code path

In this code path, the malware runs with another argument provided as the PID, for example:

  • /usr/bin/jwvwvxoupv 4849

Using the above example, the malware shares the 64-byte size memory segment with the IPC key “0xDA718716” to check for another malware process provided as an argument. If not found, it runs its own binary without any argument and calls the fork() API twice to make sure the grandchild process has no parent. This results in the grandchild process being adopted by the init process, which disconnects it from the process tree and acts as an anti-forensic technique.

Additionally, it performs the following tasks on a provided $pid:

  • Fetches the process file name corresponding to the provided $pid
  • Deletes the file for the provided $pid
  • Deletes the installed init services:
    • Deletes /etc/init.d/<file_name>
    • For runlevels 1-5, unlinks and deletes /etc/rc<runlevel>.d/S90<file_name>
    • Performs the command chkconfig –del <file_name>
    • Performs the command update-rc.d <file_name> remove
  • Ends the process that was provided as an argument.

3: Process name spoofing code path

The malware spawns new dropped binaries with two additional arguments: a fake command line and its PIDs, for example:

  • /usr/bin/jwvwvxoupv “cat resolv.conf” 4849
  • /usr/bin/jwvwvxoupv gnome-terminal 4849
  • /usr/bin/jwvwvxoupv top 4849
  • /usr/bin/jwvwvxoupv pwd 4849
  • /usr/bin/kagbjahdic id 4849

The fake commands can include:

  • cat resolv.conf
  • netstat -an
  • bash
  • whoami
  • id
  • cd /etc
  • ifconfig eth0
  • ifconfig
  • echo “find”
  • uptime
  • sh
  • top
  • gnome-terminal
  • su
  • netstat -antop
  • grep “A”
  • who
  • ls -la
  • pwd
  • route -n
  • ps -ef
  • ls
  • sleep 1

In this code path, the malware uses process name spoofing to hide from the process tree by modifying its fake command line at runtime. It then hides its process by calling HidePidPort with command “1” and reads the content of the file on disk related to the current process.

It then enters a five-second loop to perform the following checks:

  • Fetches the file name specific to the $pid provided as part of the third argument by calling the readlink API on /proc/$pid/exe.
  • If the readlink call fails, that likely indicates that the file on disk doesn’t exist. In this case, it:
    • Intends to delete all service-related entries for the $pid but fails. This appears to be due to a code flaw that allows a zeroed-out buffer to be passed as a service name when the buffer is supposed to be filled from a successful readlink API call.
    • Creates directories similar to the standard code path scenario.
    • Calls the stat API for the file /lib/libudev.so. If the stat API returns a non-zero value, then it attempts to copy the content of the current process’s image-file fetched earlier to the following locations with a random name:
      • /usr/bin/
      • /bin/
      • /tmp/   
    • Copies the /lib/libudev.so file to the same three directories listed above if the stat API call is successful on /lib/libudev.so.
    • Changes the hash of the written or copied file and then runs it without passing any parameters.
  • If the readlink call is successful and returns the count of bytes copied, sleeps for one second and then loops for the remaining time out of five seconds.
  • Unhides the current process and the $pid that was provided as part of the third argument.
  • Deletes the on-disk file for the current process.

4: Known locations code path without any provided arguments

This code path is similar to the standard code path, with the main difference being that the malware runs from one of the following locations:

  • /usr/bin/
  • /bin/
  • /tmp/

Once it runs from one of these locations, the malware calls the following functions to perform various tasks:

  1. InstallSYS – The name suggests that this function is a wrapper that should deploy a rootkit driver, but it only zeroes-out two local arrays.
Figure 14 displays a dummy InstallSYS routine that only zeros-out two local arrays.
Figure 14. Dummy InstallSYS routine
  1. AddService – Creates the persistent auto-start entries previously mentioned so that the malware runs when the system starts.
  2. HidePidPort – Hides the malware’s ports and processes.
  3. CheckLKM – Checks whether the rootkit device is active or not. It uses a similar IOCTL call with the number “0x9748712” and command “0” to find if the rootkit is active. If the rootkit is active, it uses the owner value “0xAD1473B8” and group value “0xAD1473B8” to change the ownership of dropped files with the function lchown(<filename>, 0xAD1473B8, 0xAD1473B8).
  4. decrypt_remotestr – Decodes remote URLs using the same XOR key, “BB2FA36AAA9541F0”, to decode config.rar and the other directories. After decoding the URLs, it adds them into a remote list, which is later used to communicate and fetch commands from the command and control (C2) server:
    • www[.]enoan2107[.]com:3306
    • www[.]gzcfr5axf6[.]com:3306

Malicious activity threads

After creating persistent entries, deleting evidence of its activities, and decoding config.rar, the malware initializes a cyclic redundancy check (CRC) table followed by an unnamed semaphore using the sem_init API. This semaphore is initialized with apshared value set to “0”, making the resultant semaphore shared between all the threads. The semaphore is used to maintain concurrency between threads accessing a shared object, such as kill_cfg data.

The malware then initializes three threads to perform malicious activities, such as stopping a process, creating a TCP connection, and retrieving kill_cfg data.

Figure 15 displays the semaphore and malicious thread initialization
Figure 15. Semaphore and malicious thread initialization

 kill_process

The kill_process thread performs the following tasks:

  • Decodes encrypted strings
  • Fetches file stats for /var/run/gcc.pid or, if none exist, then creates the file
  • Fetches file stats for /lib/libudev.so or, if none exist, then creates the directory /lib and creates a copy of itself at the location /lib/libudev.so
  • Fetches the on disk file information associated with the current process; if it fails, then exits the loop and stops the current process
  • Reads the content from kill_cfg and performs the corresponding actions, like stopping the process or deleting files, based on the matching specified keys in the configuration file, such as:
    • md5=
    • filename=
    • rmfile=
    • denyip=

tcp_thread

The tcp_thread triggers the connection with the C2 server decoded earlier using decrypt_remotestr(). It performs the following tasks:

  • Reads the content of the file /var/run/gcc.pid to get a unique 32-byte magic string that identifies the device while connecting with the C2 server; if the file doesn’t exist, then it creates the file and updates it with a random 32-byte string.
  • Calculates the CRC header, including details of the device such as the magic string, OS release version, malware version, rootkit presence, memory stats, CPU information, and LAN speed.
  • Encrypts the data and sends it to the C2 server.
  • Waits to receive any of the following commands from the C2 server and then acts on the command using the exec_packet subroutine.
Command Job
2 Stop
3 Create a thread pool for launching DDoS attacks
6 Download file
7 Update file
8 Send system information to the C2 server
9 Get configuration file to stop processes
Figure 16 displays code for the collection of system information.
Figure 16. Collection of system information

daemon_get_killed_process

The daemon_get_killed_processthread downloads the kill_cfg data from the remote URL decoded earlier (hxxp://aa[.]hostasa[.]org/config[.]rar) and decrypts it using the same XOR key previously mentioned. It then sleeps for 30 minutes.

Figure 17 displays code for the daemon_get_killed_process thread function fetching and decoding the kill_cfg data from remote URL.
Figure 17. daemon_get_killed_process thread function fetches and decodes the kill_cfg data from the remote URL

DDoS attack thread pool

The malware calls sysconf(_SC_NPROCESSORS_CONF) to fetch the number of processors in the device. It then creates threads with twice the number of processors found on the device.

Invoking each thread internally calls the thread routine threadwork. Using the global variable “g_stop” and commands received from the C2 server, threadwork then sends crafted packets 65,535 times to perform a DDoS attack.

Command Function Job
0x4 fix_syn   SYN flood attack
0x5 fix_dns   DNS attack
0xA fix_ack   ACK flood attack

Defending against Linux platform threats

XorDdos’ modular nature provides attackers with a versatile trojan capable of infecting a variety of Linux system architectures. Its SSH brute force attacks are a relatively simple yet effective technique for gaining root access over a number of potential targets.

Adept at stealing sensitive data, installing a rootkit device, using various evasion and persistence mechanisms, and performing DDoS attacks, XorDdos enables adversaries to create potentially significant disruptions on target systems. Moreover, XorDdos may be used to bring in other dangerous threats or to provide a vector for follow-on activities.

XorDdos and other threats targeting Linux devices emphasize how crucial it is to have security solutions with comprehensive capabilities and complete visibility spanning numerous distributions of Linux operating systems. Microsoft Defender for Endpoint offers such visibility and protection to catch these emerging threats with its next-generation antimalware and endpoint detection and response (EDR) capabilities. Leveraging threat intelligence from integrated threat data, including client and cloud heuristics, machine learning models, memory scanning, and behavioral monitoring, Microsoft Defender for Endpoint can detect and remediate XorDdos and its multi-stage, modular attacks. This includes detecting and protecting against its use of a malicious shell script for initial access, its drop-and-execution of binaries from a world-writable location, and any potential follow-on activities on endpoints.

Defenders can apply the following mitigations to reduce the impact of this threat:

  • Encourage the use of Microsoft Edge—available on Linux and various platforms—or other web browsers that support Microsoft Defender SmartScreen, which identifies and blocks malicious websites, including phishing sites, scam sites, and sites that contain exploits and host malware.
  • Use device discovery to find unmanaged Linux devices on your network and onboard them to Microsoft Defender for Endpoint. 
  • Turn on cloud-delivered protection in Microsoft Defender Antivirus or the equivalent for your antivirus product to use cloud-based machine learning protections that can block a huge majority of new and unknown variants. 
  • Run EDR in block mode so that Microsoft Defender for Endpoint can block malicious artifacts, even when your non-Microsoft antivirus doesn’t detect the threat or when Microsoft Defender Antivirus is running in passive mode.
  • Enable network protection to prevent applications or users from accessing malicious domains and other malicious content on the internet. 
  • Enable investigation and remediation in full automated mode to allow Microsoft Defender for Endpoint to take immediate action on alerts to resolve breaches, significantly reducing alert volume. 

As threats across all platforms continue to grow in number and sophistication, security solutions must be capable of providing advanced protection on a wide range of devices, regardless of the operating system in use. Organizations will continue to face threats from a variety of entry points across devices, so Microsoft continues to heavily invest in protecting all the major platforms and providing extensive capabilities that organizations needed to protect their networks and systems.

Detection details

Microsoft Defender for Endpoint detects and blocks XorDdos components and behavior as the following malware:

  • DoS:Linux/Xorddos.A
  • DoS:Linux/Xorddos!rfn
  • Trojan:Linux/Xorddos
  • Trojan:Linux/Xorddos.AA
  • Trojan:Linux/Xorddos!rfn
  • Behavior:Linux/Xorddos.A

When XorDdos is detected on a device, Microsoft 365 Defender raises an alert, which shows the complete attack chain, including the process tree, file information, user information, and prevention details.

Figure 18. Microsoft 365 Defender alert for detection of XorDdos malware

The timeline view displays all of the detection and prevention events associated with XorDdos, providing details such as the MITRE ATT&CK techniques and tactics, remediation status, and event entities graph.

Figure 19. Microsoft 365 Defender timeline displaying that HFLgGwYfSC.elf was run from a world-writable directory and the remediation of dropped binaries

Events with the following titles indicate threat activity related to XorDdos:

  • The content of libudev.so was collected into libudev.so.6
  • bash process performed System Information Discovery by invoking ifconfig
  • gcc.sh was executed after being dropped by HFLgGwYfSC.elf
  • A shell command was executed by crond
  • SUID/SGID process unix_chkpwd executed
Figure 20. Microsoft 365 Defender timeline with an event on a suspicious shell command run by crond after it was dropped from HFLgGwYfSC.elf

Hunting queries

To locate malicious activity related to XorDdos activity, run the following advanced hunting queries in Microsoft 365 Defender or Microsoft Defender Security Center:

Failed sign-ins

DeviceLogonEvents
| where InitiatingProcessFileName == "sshd"
    and ActionType == "LogonFailed"
| summarize count() by dayOfYear = datetime_part("dayOfYear", Timestamp)
| sort by dayOfYear 
| render linechart

Creation of the XorDdos-specific dropped files

DeviceFileEvents
| extend FullPath=strcat(FolderPath, FileName)
| where FullPath in ("/etc/cron.hourly/gcc.sh", "/lib/libudev.so.6", "/lib/libudev.so", "/var/run/gcc.pid")

Command-line of malicious process

DeviceProcessEvents
| where ProcessCommandLine contains "cat resolv.conf"

Indicators

File information

File name: HFLgGwYfSC.elf
File size: 611.22 KB (625889 bytes)
Classification: DoS:Linux/Xorddos.A
MD5: 2DC6225A9D104A950FB33A74DA262B93
Sha1: F05194FB2B3978611B99CFBF5E5F1DD44CD5E04B
Sha256: F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432
File type: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for GNU/Linux 2.6.9, not stripped
First submission in VT: 2022-01-25 05:32:10 UTC

Dropped files

Dropped file path File type SHA-256
/etc/init.d/HFLgGwYfSC.elf Shell Script 6E506F32C6FB7B5D342D1382989AB191C6F21C2D311251D8F623814F468952CF
/etc/cron.hourly/gcc.sh Shell Script CBB72E542E8F19240130FC9381C2351730D437D42926C6E68E056907C8456459
/lib/libudev.so ELF F2DF54EB827F3C733D481EBB167A5BC77C5AE39A6BDA7F340BB23B24DC9A4432
/run/gcc.pid Text 932FEEF3AB6FCCB3502F900619B1F87E1CB44A7ADAB48F2C927ECDD67FF6830A
/usr/bin/djtctpzfdq ELF 53F062A93CF19AEAA2F8481B32118A31B658A126624ABB8A7D82237884F0A394
/usr/bin/dmpyuitfoq ELF 798577202477C0C233D4AF51C4D8FB2F574DDB3C9D1D90325D359A84CB1BD51C
/usr/bin/fdinprytpq ELF 2B4500987D50A24BA5C118F506F2507362D6B5C63C80B1984B4AE86641779FF3
/usr/bin/jwvwvxoupv ELF 359C41DA1CBAE573D2C99F7DA9EEB03DF135F018F6C660B4E44FBD2B4DDECD39
/usr/bin/kagbjahdic ELF E6C7EEE304DFC29B19012EF6D31848C0B5BB07362691E4E9633C8581F1C2D65B
/usr/bin/kkldnszwvq ELF EF0A4C12D98DC0AD4DB86AADD641389C7219F57F15642ED35B4443DAF3FF8C1E
/usr/bin/kndmhuqmah ELF B5FBA27A8E457C1AB6573C378171F057D151DC615D6A8D339195716FA9AC277A
/usr/bin/qkxqoelrfa ELF D71EA3B98286D39A711B626F687F0D3FC852C3E3A05DE3F51450FB8F7BD2B0D7
/usr/bin/sykhrxsazz ELF 9D6F115F31EE71089CC85B18852974E349C68FAD3276145DAFD0076951F32489
/usr/bin/tcnszvmpqn ELF 360A6258DD66A3BA595A93896D9B55D22406D02E5C02100E5A18382C54E7D5CD
/usr/bin/zalkpggsgh ELF DC2B1CEE161EBE90BE68561755D99E66F454AD80B27CEBE3D4773518AC45CBB7
/usr/bin/zvcarxfquk ELF 175667933088FBEBCB62C8450993422CCC876495299173C646779A9E67501FF4
/tmp/bin/3200 ELF(rootkit) C8F761D3EF7CD16EBE41042A0DAF901C2FDFFCE96C8E9E1FA0D422C6E31332EA

Download URLs

  • www[.]enoan2107[.]com:3306
  • www[.]gzcfr5axf6[.]com:3306
  • hxxp://aa[.]hostasa[.]org/config.rar

Ratnesh Pandey, Yevgeny Kulakov, and Jonathan Bar Or
Microsoft 365 Defender Research Team

The post Rise in XorDdos: A deeper look at the stealthy DDoS malware targeting Linux devices appeared first on Microsoft Security Blog.

Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn

April 26th, 2022 No comments

Microsoft has discovered several vulnerabilities, collectively referred to as Nimbuspwn, that could allow an attacker to elevate privileges to root on many Linux desktop endpoints. The vulnerabilities can be chained together to gain root privileges on Linux systems, allowing attackers to deploy payloads, like a root backdoor, and perform other malicious actions via arbitrary root code execution. Moreover, the Nimbuspwn vulnerabilities could potentially be leveraged as a vector for root access by more sophisticated threats, such as malware or ransomware, to achieve greater impact on vulnerable devices.

We discovered the vulnerabilities by listening to messages on the System Bus while performing code reviews and dynamic analysis on services that run as root, noticing an odd pattern in a systemd unit called networkd-dispatcher. Reviewing the code flow for networkd-dispatcher revealed multiple security concerns, including directory traversal, symlink race, and time-of-check-time-of-use race condition issues, which could be leveraged to elevate privileges and deploy malware or carry out other malicious activities. We shared these vulnerabilities with the relevant maintainers through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR). Fixes for these vulnerabilities, now identified as CVE-2022-29799 and CVE-2022-29800, have been successfully deployed by the maintainer of the networkd-dispatcher, Clayton Craft. We wish to thank Clayton for his professionalism and collaboration in resolving those issues. Users of networkd-dispatcher are encouraged to update their instances.

As organizational environments continue to rely on a diverse range of devices and systems, they require comprehensive solutions that provide cross-platform protection and a holistic view of their security posture to mitigate threats, such as Nimbuspwn. The growing number of vulnerabilities on Linux environments emphasize the need for strong monitoring of the platform’s operating system and its components. Microsoft Defender for Endpoint enables organizations to gain this necessary visibility and detect such threats on Linux devices, allowing organizations to detect, manage, respond, and remediate vulnerabilities and threats across different platforms, including Windows, Linux, Mac, iOS, and Android.

In this blog post, we will share some information about the affected components and examine the vulnerabilities we uncovered. Detailing how our cross-domain visibility helps us uncover new and unknown threats to continually improve security, we are also sharing details from our research with the larger security community to underscore the importance of securing platforms and devices.

Background – D-Bus

D-Bus (short for “Desktop-Bus”) is an inter-process communication channel (IPC) mechanism developed by the freedesktop.org project. D-Bus is a software-bus and allows processes on the same endpoint to communicate by transmitting messages and responding to them. D-Bus supports two main ways of communicating:

  1. Methods – used for request-response communications.
  2. Signals – used for publish/subscribe communications.

An example of D-Bus usage would be receiving a video chat by a popular video conferencing app–once a video is established, the video conferencing app could send a D-bus signal publishing that a call has started. Apps listening to that message could respond appropriately–for example, mute their audio.

There are many D-Bus components shipped by default on popular Linux desktop environments. Since those components run at different privileges and respond to messages, D-Bus components are an attractive target for attackers. Indeed, there have been interesting vulnerabilities in the past related to buggy D-Bus services, including USBCreator Elevation of Privilege, Blueman Elevation of Privilege by command injection, and other similar scenarios.

D-Bus exposes a global System Bus and a per-session Session Bus. From an attacker’s perspective, the System Bus is more attractive since it will commonly have services that run as root listening to it.

D-Bus name ownership

When connecting to the D-Bus, components are assigned with a unique identifier, which mitigates against attacks abusing PID-recycling. The unique identifier starts with a colon and has numbers in it separated by dots, such as “:1.337”. Components can use the D-Bus API to own identifiable names such as “org.freedesktop.Avahi” or “com.ubuntu.SystemService”. For D-Bus to allow such ownership, the requesting process context must be allowed under the D-Bus configuration files. Those configuration files are well documented and maintained under /usr/local/share/dbus-1/system.conf and /usr/local/share/dbus-1/session.conf (on some systems under /usr/local/dbus-1 directly). Specifically, the default system.conf does not allow ownership unless specified otherwise in other included configuration files (commonly under /etc/dbus-1/system.d).

Figure 1 displays different ownership policies for the System Bus and the Session Bus;
Figure 1: Different ownership policies for the System Bus and the Session Bus

Additionally, if the name requested already exists–the request will not be granted until the owning process releases the name.

Vulnerability hunting

Our team has started enumerating services that run as root and listen to messages on the System Bus, performing both code reviews and dynamic analysis. We have reported two information leak issues as a result:

  1. Directory Info Disclosure in Blueman
  2. Directory Info Disclosure in PackageKit (CVE-2022-0987)

While these are interesting, their severity is low – an attacker can list files under directories that require high permissions to list files under. Then we started noticing interesting patterns in a systemd unit called networkd-dispatcher. The goal of networkd-dispatcher is to dispatch network status changes and optionally perform different scripts based on the new status. Interestingly, it runs on boot as root:

Figure 2 displays networkd-dispatcher running as root.
Figure 2: networkd-dispatcher running as root

Code flow for networkd-dispatcher

Upon examination of the networkd-dispatcher source code, we noticed an interesting flow:

  1. The register function registers a new signal receiver for the service “org.freedesktop.network1” on the System Bus, for the signal name ”PropertiesChanged”.
  2. The ”_receive_signal“ signal handler will perform some basic checks on the object type being sent, concludes the changed network interface based on the object path being sent, and then concludes its new states–“OperationalState” and “AdministrativeState”–each fetched from the data. For any of those states–if they aren’t empty–the “handle_state” method will get invoked.
  3. The “handle_state” method simply invokes “_handle_one_state“ for each of those two states.
  4. _handle_one_state” validates the state isn’t empty and checks if it’s different than the previous state. If it is, it will update the new state and invoke the “_run_hooks_for_state” method, which is responsible of discovering and running the scripts for the new state.
  5. _run_hooks_for_state” implements the following logic:
    • Discovers the script list by invoking the “get_script_list” method (which gets the new state as a string). This method simply calls “scripts_in_path” which is intended to return all the files under “/etc/networkd-dispatcher/<state>.d” that are owned by the root user and the root group, and are executable.
    • Sorts the script list.
    • Runs each script with subprocess.Popen while supplying custom environment variables.
Figure 3 displays a snippet of the _run_hooks_for_state source code.
Figure 3: _run_hooks_for_state source code – some parts omitted for brevity

Step 5 has multiple security issues:

  1. Directory traversal (CVE-2022-29799): none of the functions in the flow sanitize the OperationalState or the AdministrativeState. Since the states are used to build the script path, it is possible that a state would contain directory traversal patterns (e.g. “../../”) to escape from the “/etc/networkd-dispatcher” base directory.
  2. Symlink race: both the script discovery and subprocess.Popen follow symbolic links.
  3. Time-of-check-time-of-use (TOCTOU) race condition (CVE-2022-29800): there is a certain time between the scripts being discovered and them being run. An attacker can abuse this vulnerability to replace scripts that networkd-dispatcher believes to be owned by root to ones that are not.
Figure 4 displays building the script list in the "scripts_in_path" method, including the vulnerable code with "subdir" poisoned, which is highlighted with a red box over the text reading "os.path.join(one path, subdir, filename)".
Figure 4: Building the script list in the “scripts_in_path” method, including the vulnerable code with “subdir” poisoned.

Exploitation

Let us assume an adversary has a malicious D-Bus component that can send an arbitrary signal. An attacker can therefore do the following:

  1. Prepare a directory ”/tmp/nimbuspwn” and plant a symlink ”/tmp/nimbuspwn/poc.d“ to point to “/sbin”. The “/sbin” directory was chosen specifically because it has many executables owned by root that do not block if run without additional arguments. This will abuse the symlink race issue we mentioned earlier.
  2. For every executable filename under “/sbin” owned by root, plant the same filename under “/tmp/nimbuspwn”. For example, if “/sbin/vgs” is executable and owned by root, plant an executable file “/tmp/nimbuspwn/vgs” with the desired payload. This will help the attacker win the race condition imposed by the TOCTOU vulnerability.
  3. Send a signal with the OperationalState “../../../tmp/nimbuspwn/poc”. This abuses the directory traversal vulnerability and escapes the script directory.
  4. The networkd-dispatcher signal handler kicks in and builds the script list from the directory “/etc/networkd-dispatcher/../../../tmp/nimbuspwn/poc.d”, which is really the symlink (“/tmp/nimbuspwn/poc.d”), which points to “/sbin”. Therefore, it creates a list composed of many executables owned by root.
  5. Quickly change the symlink “/tmp/nimbuspwn/poc.d” to point to “/tmp/nimbuspwn”. This abuses the TOCTOU race condition vulnerability–the script path changes without networkd-dispatcher being aware.
  6. The dispatcher starts running files that were initially under “/sbin” but in truth under the “/tmp/nimbuspwn” directory. Since the dispatcher “believes” those files are owned by root, it executes them blindly with subprocess.Popen as root. Therefore, our attacker has successfully exploited the vulnerability.

Note that to win the TOCTOU race condition with high probability, we plant many files that can potentially run. Our experiments show three attempts were enough to win the TOCTOU race condition.

Figure 5 displays a flow-chart of the attack in 3 stages. The first 3 steps are depicted in the top image, displaying the attacker's initial steps. The 4th step is depicted in the middle image, displaying how networkd-dispatcher processes the attacker's modifications. Steps 5 and 6 are depicted in the final image, displaying how the attacker abuses the TOCTOU race condition flaw so that the dispatcher ultimately permits the Nimbuspwn exploit.
Figure 5: Flow-chart of the attack in three stages

Since we do not wish to run the exploit every time we want to run as root, the payload that we ended up implementing leaves a root backdoor as such:

  1. Copies /bin/sh to /tmp/sh.
  2. Turns the new /tmp/sh it into a Set-UID (SUID) binary.
  3. Run /tmp/sh -p. The “-p” flag is necessary since modern shells drop privileges by design.

Owning the bus name

The astute reader will notice that the entire exploit elevates privileges assuming our exploit code can own the “org.freedesktop.network1” bus name. While this sounds non-trivial, we have found several environments where this happens. Specifically:

  1. On many environments (e.g. Linux Mint) the service systemd-networkd that normally owns the “org.freedesktop.network1” bus name does not start at boot by default.
  2. Using advanced hunting in Microsoft Defender for Endpoint we were able to spot several processes running as the systemd-network user (which is permitted to own the bus name we require) running arbitrary code from world-writable locations. These include several gpgv plugins (launched when apt-get installs or upgrades) as well as the Erlang Port Mapper Daemon (epmd) which allows running arbitrary code under some scenarios.

The query we used can also be run by Microsoft Defender for Endpoint customers:

DeviceProcessEvents
| where Timestamp > ago(5d)
    and AccountName == "systemd-network"
    and isnotempty(InitiatingProcessAccountName)
    and isnotempty(FileName)
| project DeviceId, FileName, FolderPath, ProcessCommandLine

We were therefore able to exploit these scenarios and implement our own exploit:

Figure 6 displays our successfully implemented exploit after winning the TOCTOU race condition. The title reads "Nimbuspwn: networkd-dispatcher Linux EoP by Jonathan Bar Or ('JBO')". The processes are then displayed, reading top to bottom: "Attempting to own dbus name org.freedesktop.network1", "Validating name patterns", "Planting base directory", "Planting symlink", "Planting payload", it then takes four attempts to "win the (TOCTOU) race" condition before stating "Great, we now have a root backdoor. Hurray! Enjoy your root privileges".
Figure 6: Our exploit implemented and winning the TOCTOU race

While capable of running any arbitrary script as root, our exploit copies /bin/sh to the /tmp directory, sets /tmp/sh as a Set-UID (SUID) executable, and then invokes “/tmp/sh -p”. Note that the “-p” flag is necessary to force the shell to not drop privileges.

Hardening device security and detection strategy

Despite the evolving threat landscape regularly delivering new threats, techniques, and attack capabilities, adversaries continue to focus on identifying and taking advantage of unpatched vulnerabilities and misconfigurations as a vector to access systems, networks, and sensitive information for malicious purposes. This constant bombardment of attacks spanning a wide range of platforms, devices, and other domains emphasizes the need for a comprehensive and proactive vulnerability management approach that can further identify and mitigate even previously unknown exploits and issues.

Microsoft’s threat and vulnerability management capabilities help organizations monitor their overall security posture, providing real-time insights into risk with continuous vulnerability discovery, contextualized intelligent prioritization, and seamless one-click flaw remediation. Leveraging our research into the Nimbuspwn vulnerabilities to improve solutions, our threat and vulnerability management already covers CVE-2022-29799 and CVE-2022-29800 and indicates such vulnerable devices in the threat and vulnerability module in Microsoft Defender for Endpoint.

To address the specific vulnerabilities at play, Microsoft Defender for Endpoint’s endpoint detection and response (EDR) capabilities detect the directory traversal attack required to leverage Nimbuspwn. Additionally, the Microsoft Defender for Endpoint detection team has a generic detection for suspicious Set-UID process invocations, which detected our exploit without prior knowledge.

Figure 7 displays Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit - including the alert story and details of the detected activity.
Figure 7: Microsoft Defender for Endpoint detecting a suspicious SUID process used in our exploit

Defending against the evolving threat landscape requires the ability to protect and secure users’ computing experiences, be it a Windows or non-Windows device. Microsoft continuously enriches our protection technologies through robust research that protects users and organizations across all the major platforms every single day. This case displayed how the ability to coordinate such research via expert, cross-industry collaboration is vital to effectively mitigate issues, regardless of the vulnerable device or platform in use. By sharing our research and other forms of threat intelligence, we can continue to collaborate with the larger security community and strive to build better protection for all.

Jonathan Bar Or

Microsoft 365 Defender Research Team

The post Microsoft finds new elevation of privilege Linux vulnerability, Nimbuspwn appeared first on Microsoft Security Blog.

Microsoft Joins Open Source Security Foundation

August 3rd, 2020 No comments

Microsoft has invested in the security of open source software for many years and today I’m excited to share that Microsoft is joining industry partners to create the Open Source Security Foundation (OpenSSF), a new cross-industry collaboration hosted at the Linux Foundation. The OpenSSF brings together work from the Linux Foundation-initiated Core Infrastructure Initiative (CII), …

Microsoft Joins Open Source Security Foundation Read More »

The post Microsoft Joins Open Source Security Foundation appeared first on Microsoft Security Response Center.

Categories: Linux, Open Source, OpenSSF, security Tags:

VM Depot repository off to a flying start

February 11th, 2013 No comments

It’s been just one month since Microsoft Open Technologies announced the early preview of VM Depot, a community-driven catalog of open source virtual machine images. Today we are proud to announce that the community has rallied to our call and already produced over 100 images. We are thrilled at the reception this preview has received and there are more images appearing every day. VM Depot, even in preview, is already a valuable resource for open source projects and their communities. On VM Depot the community can build, deploy and share their favorite Linux configuration, create custom open source stacks, work with others and build new architectures for the cloud that leverage the openness and flexibility of the Windows Azure platform.

We already have a range of base Linux distributions upon which you can build new images. These include, but are not limited to, Debian, Centos, Ubuntu and Mageia. There are images that include “big brand” open source projects such as WordPress, Drupal as well as developer stacks such as the LAMP, Ruby Stack and Apache Tomcat. All these are complemented nicely by more niche projects such as the Moodle course management system and PhPCompta, an accounting application adapted to Belgian legislation. Each day we are seeing more and more open source software published on VM Depot for deployment to Windows Azure. I can only thank the growing community for so fully embracing the VM Depot preview. It’s great to arrive here at Microsoft just as this is taking off, I look forward to working with you as we go from strength to strength.

If you haven’t already done so, now is a really good time to take a look at the ever growing range of images available. If you have an Azure subscription, you’re ready to try it out, if not you can quickly sign up for a free 90-day trial subscription. In addition to being able to deploy from your Azure portal we have provided cross-platform command line tools that give you all the control you need. All we ask is that you remember this is a community effort so please rate and comment on any images you try out. This will help users find the best images and help maintainers ensure they are meeting user’s needs.

Should the image you are looking for not be available yet you can let the community know via the VM Depot forums, with luck someone else will have the same need and publish their image for you. Alternatively, you can build and publish an image yourself. Instructions for publishing and managing images are available on the VM Depot website. If you need any assistance please post to the forums where I or another community member will be pleased to help you.

It is clear from the communities uptake of VM Depot that open source is front and center on Windows Azure, with your help we look forward to building on the early momentum this preview release has generated.

For your OSS image building and sharing pleasure … meet VM Depot from MS Open Tech

January 9th, 2013 No comments

By Gianugo Rabellino
Senior Director Open Source Communities
Microsoft Open Technologies, Inc.

As I write this, I’m exploring the public preview of VM Depot, a new service from Microsoft Open Technologies, Inc. VM Depot is a community-driven catalog of open source virtual machine images for Windows Azure. On VM Depot the community can build, deploy and share their favorite Linux configuration, create custom open source stacks, work with others and build new architectures for the cloud that leverage the openness and flexibility of the Windows Azure platform.

The preview launch of VM Depot today is an introduction of things to come: you can already easily deploy different Linux-based virtual machines that include custom and curated installations and configurations. (We have the latest, full-fledged distributions of Debian, Alt Linux and Mageia for your hacking pleasure.) You can comment on them. You can rate them. And, what’s more, you can remix them to your liking and possibly share the results with other members of the community. Or why don’t you go ahead and just create a new one from scratch with your favorite software? For ultimate speed, you can quickly deploy images already customized for specific business scenarios. All this is just a few clicks away, completely free of charge and just waiting for your input to make it better. To learn more, see Getting Started with VM Depot.

VM Depot is another illustration of how the Azure platform is effectively open. As complex as it may seem, VM Depot was relatively easy to build as it relies exclusively on published Azure APIs. As we explore the meaning of openness and interoperability of cloud platforms, I can now say that Windows Azure is at the forefront of the debate and provides compelling proof that documented APIs can do wonders to enable building amazing new applications that leverage the cloud.

Some days you can’t help smiling. I had a big smile on my face back in June when Microsoft announced it was making preconfigured Linux images available in Windows Azure gallery and today I have another reason to be happy as I see how Microsoft Open Technologies is helping open source communities work even more collaboratively with the Windows Azure platform.

VM Depot wouldn’t have been possible without the support of a number of partners who have contributed images and packages for this preview launch, including Alt Linux, Basho, Bitnami and Hupstream. Here what they have to say about VM Depot:

“Ease of deployment is one of the key discussions we have with all of the companies leveraging Riak for their highly-available, scalable data storage needs. The VM Depot indicates that Microsoft Open Technologies is dedicated to supporting the needs of today’s enterprise with the Windows Azure Platform” – Tyler Hannan, Director of Technical Marketing, Basho Technologies, Inc.

“The launch of Azure Virtual Images and now the VM Depot demonstrate that Microsoft is serious about building out its cloud computing platform. We are thrilled to be a part of this new marketplace, which simplifies deployment of the top open source applications to the enterprise-ready Azure platform, taking Windows Azure to a whole new level.” – Erica Brescia, CEO of BitRock, developers of Bitnami

“The demand for cloud computing is there, and Hupstream had the skills to adapt a distribution to the specifics of cloud computing, and provide support as needed. We also wanted to make Debian and Mageia more accessible, and cloud platforms are the simplest way to get started. This was also an opportunity to establish a conversation between actors that traditionally shun each other. Notably, we had excellent collaboration with Microsoft engineers and other community members, while working on a common goal: expanding the reach of developers with Linux.” – Romain d’Alverny, Managing Partner & Engineer at hupstream

I have been doing a fair amount of traveling for MS Open Tech lately where I’ve met a number of great people from the open source community. After a wonderful holiday break, we’re off to an exciting and busy New Year. I know I will use every free moment this month to peek at the VM Depot dashboard and see our latest creation take its first baby steps. Expect more in the upcoming weeks and please help us make VM Depot the best place for open source communities to work together and build shared images for the cloud. See you there.

Categories: Linux, Open Source, Windows Azure Tags:

A New Milestone For Openness On Windows Azure

June 6th, 2012 No comments

Today Bill Laing, Corporate VP for Server and Cloud, announced a very important set of Windows Azure updates. With these new updates, Windows Azure is more than ever an open and easy platform to build and run applications in the cloud, and the place to be for developers who want to have choice and flexibility.

I am proud to say that Microsoft Open Technologies, Inc. has been working closely with the Windows Azure team and it has been a great journey together, exploring openness and taking interoperability to a new level. There is too much news in this release to cover in a single blog post, and I strongly suggest everyone attend the Meet Windows Azure event tomorrow, when Scott Guthrie and many others will provide a lot of additional information. At the same time, I would like to spend the next few paragraphs on some of the many facets of openness in Windows Azure, to further demonstrate how Windows Azure is living in interesting and exciting times.

Services and Partnerships

For one, I have to point out how all-encompassing the Windows Azure platform is becoming. We will talk in a minute about the support for IaaS, but I would like to draw your attention to how the Windows Azure platform has now announced a set of partnerships that will provide very compelling data services such as MySQL, CouchDB, and Apache Solr.

Those services can be enjoyed by PaaS and IaaS developers and come from the leading industry experts in the field: Microsoft is partnering with leading companies such as Cleardb, Cloudant and Lucid Imagination to provide true data-as-a-service and enable developers and customers to build applications at scale without the worry of provisioning and maintaining their databases. At the same time we and our partners addressed the needs of those who prefer to run software independently in their own PaaS and/or IaaS instances, providing easy installation packages of Windows Azure-optimized versions of Apache CouchDB and Apache Solr. Last but not least, we worked with 10gen to improve the installation experience of MongoDB on Windows Azure that was originally announced in December, and we are looking forward to building a great experience for Windows Azure MongoDB users. 

More importantly, both Microsoft and our partners are committed to always maintain full compatibility with the underlying Open Source applications so that our customers can always rest assured their data will work everywhere. With these technologies joining the existing pool of Windows Azure SQL Database and Apache Hadoop, Windows Azure is leading by leaps and bounds when it comes to data.

OSS on Windows Azure

If Windows Azure databases are now a few clicks away, applications are far from being out in the cold. The announcement of Windows Azure Web Sites – a hosting framework for Web apps that will work across both Windows Azure and private-cloud datacenters – unveils amazing opportunities to run popular Open Source applications in Windows Azure: be it WordPress or Drupal, Joomla or Umbraco, DotNetNuke or PHPBB, or one of the many apps in the Web Sites gallery, it has never been easier to deploy applications on the Windows Azure platform. And I can’t wait for developers to try the new releases of the Windows Azure open source SDKs (now including Python in addition to .NET, Java, PHP and Node.js) as well as the integration with Git.

We are also releasing a major update to the Windows Azure Plugin for Eclipse with Java (by Microsoft Open Technologies that includes a number of user feedback-driven improvements. Among them is a significantly revamped deployment experience contributed by GigaSpaces Technologies Ltd, an established leader in helping enterprises move their Java applications to the cloud, who has recently joined in the development work behind the plugin. Their impressive “publish to cloud” wizard makes it much easier for Windows Azure developers working with Java to deploy their projects to the Windows Azure cloud directly from Eclipse. Read the more detailed blog post from Martin Sawicki that covers the Eclipse plugin in more detail.

Last but not least, you probably have noticed the upcoming support for IaaS, Virtual Machines and Linux. I believe this move demonstrates how Windows Azure is built around what customers are asking for and with the idea of being the most inclusive platform ever. Customers are demanding high degrees of flexibility and want to be able to run every possible scenario in a seamless fashion: there are very interesting examples of hybrid private/public clouds out there, not to mention a number of creative contaminations of IaaS, PaaS and data services. We are most definitely moving away from monolithic architectures – customers and developers today want and deserve flexibility.

Linux on Windows Azure

Enabling use of Linux on Windows Azure is a key piece of the puzzle, and needs to be as easy as possible. As with data services, it’s all about strong partnerships with industry leaders: this is why you are seeing Windows Azure partnering with major Linux publishers to provide an amazing experience, and I’m sure this will be a very exciting and ongoing story. On top of that I have to note how partners like BitRock are doing very interesting work to provide more choice: two initial Linux images are available for Bitnami, and we look forward to extending the catalog much further.

Allow me to make a final example of openness and talk about the Windows Azure Command Line Tools for Mac and Linux (the ones Windows Azure users will run on local machines to deploy and manage their Windows and Linux virtual machines): not only they are Open Source, but they are available right now for Mac and Linux clients. And this is just the beginning – stay tuned for more exciting news.

Openness and Interoperability

When a journey reaches an important milestone it’s good to look back and think about the road so far: in my case I went as far as two years ago, when we shared our view on Interoperability Elements of a Cloud Platform. Back then we talked to customers and developers and came out with an overview of an open and interoperable cloud, based on four distinct elements: data portability, standards, ease of migration & deployment and developer choice. We have been laser focused on the quest for an interoperable and flexible cloud platform that would enable heterogeneous workloads, and it’s really rewarding to see how today’s announcement maps nicely to the vision that we outlined back then. More precisely:

  • A lot of efforts have been spent on data portability with great results. Allow me to remind you how on Windows Azure your data is either a JSON/XML call away or in any case available through open interfaces (think of JDBC/ODBC support for SQL Database, as an example). Working on open interfaces really pays off when I think of how our partners have been able to build data solutions (MySQL, Hadoop, Solr, CouchDB, MongoDB) that can run either as a service or as independent workloads. Our customer own their data, and this is near and dear to our hearts.
  • When it comes to standards Windows Azure has one of the most complete API layers around, exposed as REST, XML, OData, Atompub, JSON and others. We are working with standard bodies such as IETF, OASIS and DMTF to ensure that important topics such as identity and management in the cloud are exposed as standard-based APIs, and we have been proactive proponents of important standard efforts such as AMQP and OData among others.
  • Ease of migration & deployment is a key factor when building a cloud platform that preserves existing investments and enables co-existence between on-premise software and cloud services. I see a lot of progress in this area, as an example when I think of the work we have been doing to provide our Java customers and developers with a much improved Eclipse experience, while at the same time providing to everyone the flexibility of FTP and Git to deploy and manage applications. Windows Azure Web Sites is also a great example of how easy deployment can be in the cloud, putting your favorite applications (WordPress, Drupal, Joomla, PHPBB and many others) just one click away. While at it, you may want to check out our step-by-step instructions for running Magento.
  • And finally, developer choice, defined as the possibility to use a variety of development tools, runtime and languages. Here we have five SDKs layered on top of a standard APIs, covering .NET, Java, PHP, Python and Node.js. We support the widest possible variety of workloads: be it PaaS or IaaS, be it Windows or Linux, be it public, private or hybrid. We are working with Open Source communities and with leading vendors to provide the best of breed in applications and data services. No matter what your workload is, Windows Azure will be a great home for it.

I have broken every promise I made to myself to keep this post short, yet I barely managed to scratch the surface of this announcement. I have in front of me the plan for the upcoming weeks and I know it will be busy times for this and many other blogs in Microsoft as there is so much to share. It will all start tomorrow at the Meet Windows Azure event: be there!

OSBC 2012: Advancing Interoperability in the Cloud

May 21st, 2012 No comments

At the Open Source Business Conference in San Francisco today, Sandy Gupta, the General Manager for Microsoft’s Open Solutions Group, along with Alan Clark, Director of New Initiatives and Emerging Standards for Open Source at SUSE, announced the release of a beta version of the SUSE Manager Management Pack for System Center.

In a blog post, Gupta said the announcement, which was made in collaboration with SUSE, lets this management pack connect the Linux server management capabilities provided by SUSE Manager to System Center, Microsoft’s management platform.

“As a result, customers will be able to administer both Windows and Linux environments from a single management console,” he said.

Gupta positioned the management pack as one example of the work Microsoft is doing to advance interoperability for private clouds. You can try the Linux management capabilities this management pack provides for System Center here.

“On the public cloud front, there’s extensive work going on across the company to facilitate interoperability between Microsoft and open source cloud tools and services. One of the most exciting examples of this comes from the SQL Server Team — the Hadoop-based service for Windows Azure, for which Microsoft released a second preview last month,” he said.

This solution for managing “big data,” connecting it and turning it into business insight, is a prime example of the type of value customers want to realize as a result of leveraging open source and Microsoft software together, he noted.

You can read his full blog post here.

FreeBSD to run as a first-class guest on Windows Server Hyper-V

May 11th, 2012 No comments

Today, at BSDCan 2012, Microsoft and partners NetApp and Citrix announced upcoming native support for FreeBSD support on Windows Server Hyper-V.

This move continues our commitment to extend support across platforms to the Windows Server Hyper-V solution, making it easier for more customers to realize the benefits of server virtualization and more easily adopt cloud computing.

This will allow FreeBSD to run as a first-class guest on Windows Server Hyper-V. The drivers and associated source code will be released early this summer under the BSD license, and will initially work with FreeBSD 8.2 and 8.3 on Windows Server 2008 R2.

You can read more about this on the Openness blog.

Joe CaraDonna, the Technical Director of Core Operating Systems at NetApp, says in an interview that he was thrilled to have had the opportunity to work with Microsoft and Citrix to deliver Windows Server Hyper-V support to FreeBSD.

“I think the combination of these virtualization technologies helps round-out the FreeBSD virtualization story, and makes the FreeBSD operating system a more compelling offering.”

He also notes how committed Microsoft is to open source initiatives: “we decided from the very beginning that we were going to open source the code under the BSD license. No strings attached. They were as eager as us to support the project, and then give the code away. How cool is that?”

You can read the full interview here.

Announcing one more way Microsoft will engage with the open source and standards communities

April 12th, 2012 No comments

In case you missed it, I just wanted to flag this blog from Jean Paoli:

I am really excited to be able to share with you today that Microsoft has announced a new wholly owned subsidiary known as Microsoft Open Technologies, Inc., to advance the company’s investment in openness – including interoperability, open standards and open source.

My existing Interoperability Strategy team will form the nucleus of this new subsidiary, and I will serve as President of Microsoft Open Technologies, Inc.

The team has worked closely with many business groups on numerous standards initiatives across Microsoft, including the W3C’s HTML5, IETF’s HTTP 2.0, cloud standards in DMTF and OASIS, and in many open source environments such as Node.js, MongoDB and Phonegap/Cordova.

We help provide open source building blocks for interoperable cloud services and collaborate on cloud standards in DMTF and OASIS; support developer choice of programming languages to enable Node.js, PHP and Java in addition to .NET in Windows Azure; and work with the PhoneGap/Cordova and jQuery Mobile and other open source communities to support Windows Phone.

It is important to note that Microsoft and our business groups will continue to engage with the open source and standards communities in a variety of ways, including working with many open source foundations such as Outercurve Foundation, the Apache Software Foundation and many standards organizations. Microsoft Open Technologies is further demonstration of Microsoft’s long-term commitment to interoperability, greater openness, and to working with open source communities.

Today, thousands of open standards are supported by Microsoft and many open source environments including Linux, Hadoop, MongoDB, Drupal, Joomla and others, run on our platform.

The subsidiary provides a new way of engaging in a more clearly defined manner. This new structure will help facilitate the interaction between Microsoft’s proprietary development processes and the company’s open innovation efforts and relationships with open source and open standards communities.

This structure will make it easier and faster to iterate and release open source software, participate in existing open source efforts, and accept contributions from the community. Over time the community will see greater interaction with the open standards and open source worlds.

As a result of these efforts, customers will have even greater choice and opportunity to bridge Microsoft and non-Microsoft technologies together in heterogeneous environments.

I look forward to sharing more on all this in the months ahead, as well as to working not only with the existing open source developers and standards bodies we work with now, but with a range of new ones.

Thanks,

Jean

Avenda Announces $1 eAgent Introductory Pricing – From now until after the RSA Conference 2009

January 9th, 2009 Comments off

Here is a follow-up guest posting from our NAP Partner Avenda Systems.



 


Due to the interest in our recent blog entry – Five Ways to Draw More Value from Microsoft NAP Deployments – we’ve decided to help customers kick off 2009 with a little cost savings.  The calls and email have been overwhelming and have helped us understand that a lot of you are looking at role-based access and endpoint posture and health validation as a real way to leverage Microsoft’s NAP technology.


With the release of Windows Server 2008, network policy and services is something everyone should be considering to secure 802.1X-based wireless, wired, and VPN deployments.  Additionally, the NAP agent for Windows XP is in Service Pack 3, which was released worldwide earlier in 2008. As a result, a NAP client was expected to be available to some 80% or more of Windows laptops, by the end of 2008.


Avenda’s eAgents add the ability to extend Microsoft NAP capabilities and to support non-Microsoft operating systems.


From now until April 30th, one week after the end of the RSA Conference 2009 in San Francisco, each copy of our eAgents can be purchased for $1 each.  This includes the Windows and Linux NAP agents.

Categories: Linux, Partners Tags:

Avenda Announces $1 eAgent Introductory Pricing – From now until after the RSA Conference 2009

January 9th, 2009 No comments

Here is a follow-up guest posting from our NAP Partner Avenda Systems.



 


Due to the interest in our recent blog entry – Five Ways to Draw More Value from Microsoft NAP Deployments – we’ve decided to help customers kick off 2009 with a little cost savings.  The calls and email have been overwhelming and have helped us understand that a lot of you are looking at role-based access and endpoint posture and health validation as a real way to leverage Microsoft’s NAP technology.


With the release of Windows Server 2008, network policy and services is something everyone should be considering to secure 802.1X-based wireless, wired, and VPN deployments.  Additionally, the NAP agent for Windows XP is in Service Pack 3, which was released worldwide earlier in 2008. As a result, a NAP client was expected to be available to some 80% or more of Windows laptops, by the end of 2008.


Avenda’s eAgents add the ability to extend Microsoft NAP capabilities and to support non-Microsoft operating systems.


From now until April 30th, one week after the end of the RSA Conference 2009 in San Francisco, each copy of our eAgents can be purchased for $1 each.  This includes the Windows and Linux NAP agents.

Categories: Linux, Partners Tags:

Avenda Announces $1 eAgent Introductory Pricing – From now until after the RSA Conference 2009

January 9th, 2009 No comments

Here is a follow-up guest posting from our NAP Partner Avenda Systems.



 


Due to the interest in our recent blog entry – Five Ways to Draw More Value from Microsoft NAP Deployments – we’ve decided to help customers kick off 2009 with a little cost savings.  The calls and email have been overwhelming and have helped us understand that a lot of you are looking at role-based access and endpoint posture and health validation as a real way to leverage Microsoft’s NAP technology.


With the release of Windows Server 2008, network policy and services is something everyone should be considering to secure 802.1X-based wireless, wired, and VPN deployments.  Additionally, the NAP agent for Windows XP is in Service Pack 3, which was released worldwide earlier in 2008. As a result, a NAP client was expected to be available to some 80% or more of Windows laptops, by the end of 2008.


Avenda’s eAgents add the ability to extend Microsoft NAP capabilities and to support non-Microsoft operating systems.


From now until April 30th, one week after the end of the RSA Conference 2009 in San Francisco, each copy of our eAgents can be purchased for $1 each.  This includes the Windows and Linux NAP agents.

Categories: Linux, Partners Tags:

Avenda Announces $1 eAgent Introductory Pricing – From now until after the RSA Conference 2009

January 9th, 2009 No comments

Here is a follow-up guest posting from our NAP Partner Avenda Systems.



 


Due to the interest in our recent blog entry – Five Ways to Draw More Value from Microsoft NAP Deployments – we’ve decided to help customers kick off 2009 with a little cost savings.  The calls and email have been overwhelming and have helped us understand that a lot of you are looking at role-based access and endpoint posture and health validation as a real way to leverage Microsoft’s NAP technology.


With the release of Windows Server 2008, network policy and services is something everyone should be considering to secure 802.1X-based wireless, wired, and VPN deployments.  Additionally, the NAP agent for Windows XP is in Service Pack 3, which was released worldwide earlier in 2008. As a result, a NAP client was expected to be available to some 80% or more of Windows laptops, by the end of 2008.


Avenda’s eAgents add the ability to extend Microsoft NAP capabilities and to support non-Microsoft operating systems.


From now until April 30th, one week after the end of the RSA Conference 2009 in San Francisco, each copy of our eAgents can be purchased for $1 each.  This includes the Windows and Linux NAP agents.

Categories: Linux, Partners Tags: