Microsoft’s Edge news feed exploited to advance tech support scams Posted on September 27, 2022 by Obanla Opeyemi Security researchers at Malwarebytes have uncovered an ongoing malvertising campaign that injects ads into Microsoft’s Edge News Feed, redirecting potential victims to websites that promote tech support scams. The Threat Intelligence team at Malwarebytes said the fraud operation had been running for at least two months and was considered one of the most extensive campaigns due to the amount of telemetry noise generated. The attackers switch between hundreds of ondigitalocean.app subdomains to host their scam sites within a single day. The several malicious ads injected into the timeline of the Edge News Feed are also linked to more than a dozen domains. The redirect flow, which is used to send Edge users to malicious websites, begins by checking the target’s web browsers for different settings such as time zones to decide whether they are worth their time, or if not, send them to a decoy page. To redirect to their scam landing pages, the threat actors use the Taboola ad network to load a Base64-encoded JavaScript script to filter potential victims. “The goal of this script is to only show the malicious redirection to potential victims, ignoring bots, VPNs and geolocations that are not of interest that are instead shown a harmless page related to the advert. This scheme is meant to trick innocent users with fake browser locker pages, very well known and used by tech support scammers,” explained Malwarebytes. The sources for this piece include an article in BleepingComputer.
Business Value of ELS Patching for Python Posted on September 26, 2022September 26, 2022 by TuxCare Team Python has grown tremendously, and its impact has been remarkable. It has become one of the most popular programming languages among developers and researchers. Python is an object-oriented, high-level, interpreter-based programming language. It was created by Guido van Rossom in 1991 and has been used for various projects since then. The importance of Python for DevOps A recent survey of 4,600 IT professionals found that those who adopted a DevOps culture could deploy code 200% more often than those who did not embrace such a culture. They also spend half as much time applying fixes through patches for bugs, recover twice as fast after failures, and have threefold fewer changes fail. Most importantly, they achieve these results without sacrificing quality. What’s Python’s place in DevOps development tools? Python’s versatility and ease of use make it an ideal tool for DevOps workflows. Developers can write scripts and deploy them to production servers without worrying about infrastructure. Python is widely adopted across the industry, so it’s easy to find people who know how to use it. Python is one of several programming languages commonly used by teams practicing DevOps. It has many advantages compared to other languages, making it an excellent choice for this role. Buying Time to Migrate to the Following Code Release of Python Several challenges become critical to organizations once they adopt python as their central application for source code development and automation. Once a new release of Python is announced, the organization may take up to 3 years to migrate their current source code to the latest version. In the case of Python 3 not having legacy support for Python 2.7, this created a critical risk for software companies. The inability to back support a previous version places the software company in a challenging place. The company will need time to develop new code, test, QA, and stage more rapidly. This new code set will likely have more bugs and performance issues with a limited operating window. This rapid code development also places their existing clients at risk. The clients will need to either attempt an upgrade in place or possibly forklift the entire platform. Both options add to the risk for Python clients. Many clients may opt not to upgrade to the software’s new code while considering other options. Unable to receive security updates and choose to live with the inherent risk of vulnerabilities and exploits, these clients will jeopardize their most critical assets. Python developers and clients need enhanced operational security with the latest version available and extended support after the end-of-life date. Value of Tuxcare Extended Lifecycle Support(ELS) You’ve built your applications on Python, you know that code front to back, and you’ve spent years chasing instability and squashing bugs. The hard work and long days put in by your team have resulted in something that runs well and builds value for your organization. What are some of the core business justifications for investing in an ELS? Your currently targeted Python version is going to end-of-life, and you need time to develop the next-generation application. No need to refactor your Python 2.7 applications to Python 3.0 We backport security fixes for Python 2.7 versions, so you wouldn’t have to rewrite your app. Security compliance must be maintained, but an upgrade may break your code. Specific compliance regulation, including PCI-DSS, HIPAA, FEDRAMP, and NIST-800-53, requires all systems to be patched within 30 days after identifying known vulnerabilities. Extend the life of your hardware and software assets while conserving DevOps resources. Using ELS with automation delivery, patches, and updates, including rollback capability, can streamline the update process with the DevOps teams. Protecting your Python 2.7 from vulnerabilities Vulnerabilities will exist in any code, including the Python language. Many vulnerabilities never become exploits. Python, like other applications, is subject to zero-day attacks. These attacks are often executed by hackers betting on specific vulnerabilities within a system that has not been patched regularly. The hacker’s rule is most Python and other systems’ time to patch a vulnerability or patch (MTTP) is between 60 and 150 days. SecOps usually send out a patch within 38 days. The open window will most likely be when a system becomes exploited. However, no one will know which one or when the attack will occur. ELS will reduce the threat vector of zero-day attacks against Python applications as an automated business process. An unpatched vulnerability at the language level will inherently place at risk all the applications written in that language, so even if the application’s code itself does not have any issue, some language construct that is used may have, and this is both difficult to diagnose and complex to protect from adequately. Why Tuxcare? Trusted partner We’ve supported various RHEL forks for over 12 years, including AlmaLinux – a forever-free enterprise-grade OS. Support the significant Linux OS versions from CentOS 6, CentOS 7, and CentOS 8, including Ubuntu 16.04 LTS and RHEL-based distributions. Also available is ELS for PHP. Through KernelCare Enterprise, we provide live patching for the Linux Kernel, critical shared system libraries like OpenSSL and Glibc, open source databases like MySQL, Postgres, and MariaDB, and the virtualization platform QEMU/KVM – all of which cause high business disruption when patched traditionally. Being compliant is our nature We have passed and continuously maintain various Cybersecurity certifications. And our services have helped numerous enterprise companies, government agencies, and universities achieve and maintain their compliance status. The TuxCare Story TuxCare has delivered patches and bug fixes for various Linux distros for over ten years. TuxCare is approaching 1 million in production workloads secured and supported by our services. We have over 1500 customers from multiple industries around the world. TuxCare’s KernelCare Enterprise has patched more than 2,000 vulnerabilities without reboots over the years. We support more than 40 Linux distributions. Frequently Asked Questions What version of Python is supported by ELS for Python? The service will provide security updates for Python 2.7. Will existing Python code continue to run as-is? Yes – the goal is to provide security fixes, not language-breaking changes. Your existing Python 2.7 code and applications will continue to run as before – only more securely. Does this address security issues in my Python application? Depends. If the security issue stems from a language-specific security problem, your application will be secure from threats targeting that specific security problem. My application is written in Python and has no security issues – why do I need ELS for Python? New vulnerabilities emerge every day, and of those, some will target older code. Even if your application does not directly have any security problems, exposure found at the language level may make your application insecure. That is why it is essential to have access to security patches even after a language is no longer officially supported.
Hackers exploit Oracle WebLogic Servers and Docker APIs to mine Crypto Posted on September 26, 2022September 26, 2022 by Obanla Opeyemi Cybersecurity company Trend Micro has uncovered a malware campaign in which threat actors exploit security vulnerabilities in the Oracle WebLogic Server to deliver cryptocurrency mining malware. One of the malware that exploits the vulnerabilities is Kinsing malware. The operators behind Kinsing malware are notorious for looking for vulnerable servers to co-opt them into a botnet. For the latest trend, the attackers use CVE-2020-14882, a two-year-old RCE remote code execution bug that targets unpatched servers to gain control of the server and drop malicious payloads. The flaw has a severity score of 9.8. To successfully exploit the vulnerability, the attackers use a shell script that performs various sections, including removing the /car/log/syslog system logs, disabling security features and cloud service agents from Alibaba and Tencent, and killing competing mining processes. After it has been successfully deployed, the shell script downloads the Kinsing malware from a remote server and takes action to ensure persistence. Researchers from Aqua Security also identified another cryptojacking group called TeamTNT. One of TeamTNT’s attack chains aims to crack the SECP256K1 encryption, and if successful, it could allow attackers to calculate the keys to each cryptocurrency wallet. The campaign aims to use the high but illegal computing power of its targets to run the ECDLP solver and obtain the key. Two other attacks carried out by TeamTNT relate to the exploitation of exposed Redis servers and misconfigured Docker APIs to use coin miners and Tsunami binaries. According to the researchers, the accounts (alpineos and sandeep078) are reportedly used to spread a variety of malicious payloads such as rootkits, Kubernetes exploit kits, credentials stealers, XMRig Monero miners, and even the Kinsing malware. As a security measure, companies are recommended to configure the exposed REST API with TLS to mitigate hostile AiTM attacks, as well as to use credentials stores and helpers to host user data. The sources for this piece include an article in TheHackerNews.
Owner-initiated Cybersecurity Supply Chain Attacks Posted on September 23, 2022September 23, 2022 by Linux Live Patching Expert Team Supply chain attacks come in all forms and shapes. One example is taking over legitimate accounts to deploy malicious code into widely used libraries. Another is deploying changes during compilation through malicious tooling. We could carry on – think about mislabeled content intent on tricking unwary users, or additional files added that subvert application behavior. But, another particularly malicious supply chain attack perpetrated by the actual code owner or the original developer behind the code is emerging – and it’s proving to be incredibly disruptive. A new, dangerous supply chain threat This attack vector emerged early in 2022 when developers realized that a couple of very widely used libraries (“faker.js” and “colors.js”) had been tampered with to include code that was unrelated to the original intent of these libraries. Worse, the “additional” code was breaking the applications relying on it by creating an infinite loop in the code. Because the code for these libraries is open and hosted in public repositories it was possible to analyze the commits and identify who had added that malicious code. The developer community was disconcerted to find that the code was added by the original developer. Apparently unhappy with not being able to monetize the time he expended in developing the code, and how it was being used by so many developers, the developer decided to sabotage his own libraries. Sabotage that impacts millions It might sound like it’s nothing – it’s the developer’s code, after all. But to put it all into context, the affected libraries had an aggregate of 25 million downloads… not across their useful lifetime, but every single week. The politics of open source and how open source is monetized – including the steps a developer can take to address it – is really an entire article in and of itself, and opinions can vary a lot. But, for obvious reasons, the backlash around a developer tampering with code used by millions was immense. In fact, GitHub, where the code is hosted, suspended the developer’s account (though GitHub restored it a few days after). The developer claimed to have hundreds of projects, not only in those two libraries but of course, the two libraries in question have an immense following. Malicious action with real impact on developers The libraries ended up being blocked from distribution, the code was reverted, and new libraries were created to replace the functionality. What this meant for developers using those libraries was the extra work of checking code, updating it, and changing dependencies. One individual’s actions led to extra testing and all the other tasks that are necessary to ensure proper software execution. Countless work hours were spent on responding to a malicious actor, hours that could have been more productively used elsewhere. It was deliberate action by a single developer that affected thousands of applications. But there are other situations where it’s not deliberate, but it nonetheless comes from the source, the developer. Or, at least, the developer’s account. A compromised git server Just a couple of months after that, in March, the git server holding the code for the most popular web server programming language, PHP, was compromised. Yes, you read the right, the PHP Team’s official PHP git repository was tampered with. Attackers managed to change the source code for PHP 8.1 and introduce malicious commits into the system under the guise of “typo fixes”, which hid malicious code that, if successfully integrated into the PHP codebase, would disseminate to millions of PHP deployments and create a backdoor in millions of internet-facing websites and services written in PHP. How did it happen? Git is a great tool, but it has a flaw where it is possible to sign code commits as someone else. Another person reviewing the code edits may then be fooled into thinking that the edits were made by, say, the main project developer. The result is that any review could rely heavily on trust – the trust that the right person edited the code and made acceptable changes. Reviews can therefore be less stringent, allowing malicious code to slip under the radar undetected. And it’s not just PHP… The malicious code added to PHP 8.1 was detected and the commits were rejected, so the code never made it into the PHP codebase millions use every day. Yet the problem it created led the team to move from its own git repository to GitHub. In May, Python’s ctx library and PHP’s phpass library were both compromised in an operation that the attacker claimed was simply “for research purposes”, a claim that was ultimately impossible to prove or disprove. In a convoluted series of steps, the attacker took over the repositories for these libraries by impersonating the original developers – taking over email addresses that no longer existed, then requesting password recovery for those accounts, and creating fake domains to validate ownership of expired ones. This tricked the repository hosts into giving repository administration to the attacker, who was posing as the original developer who had lost access to his own code. The attacker proceeded to include credential-stealing code in those libraries, including AWS credentials. The attacker’s claims that all the gathered credentials were deleted were also impossible to verify. Threat actors are investing heavily in supply chain attacks These examples shine a light on the need for a quick response to threats in the code supply chain. The threat to code supply chains is not new in and of itself. However, the attacks we’re seeing lately are different because the time invested goes much beyond the usual attack turnaround time of days or weeks. The latest examples of compromises involve a huge amount of time to execute the compromise. In many ways it is a much more serious example of a supply chain attack, striking at the heart of code that is – blindly – used by millions of organizations around the world. In another point that makes the matter more serious: it’s worth considering the large amount of work required to change library versions to respond to a compromise. New libraries take a considerable amount of time to execute, test and deploy each time such an event takes place. This is where a service like Extended Lifecycle Support for PHP and Extended Lifecycle for Python can help. TuxCare quickly provides security updates for language level issues and for related modules, which help close holes created by some of the attacks we described faster and with less work than the alternatives.
U.S. Seizes $30 Million Worth of Crypto from North Korean Hackers Posted on September 23, 2022September 20, 2022 by Obanla Opeyemi Chainalysis, a U.S. company, said it had worked with the FBI to recover more than $30 million in cryptocurrency stolen from online video game maker Axie Infinity by North Korea-linked Lazarus Group, marking the first time digital assets seized by the malicious attacker have been recovered. The amount recovered is just a percentage of the estimated $600 million that the FBI alleges North Korean hackers stole from the makers of a popular video game that allows users to earn digital currency. “The seizures represent approximately 10% of the total funds stolen from Axie Infinity (accounting for price differences between time stolen and seized), and demonstrate that it is becoming more difficult for bad actors to successfully cash out their ill-gotten crypto gains,” Erin Plante, senior director of investigations at Chainalysis said. Plante, Chainalysis’ lead investigator said the seizure, which will not be the last, is a significant development for law enforcement, and investigators are working hard to seize the remaining loot. According to Plante, the chain analysis was involved in the seizures, using “advanced tracking techniques to track stolen funds to withdraw ATMs, and working with law enforcement and industry stakeholders to quickly freeze funds.” The Lazarus Group had access to five of the nine private keys owned by transaction validators for Ronin Network’s cross-chain bridge. Subsequently, the group facilitated two withdrawal transactions: one for 173,600 Ether (ETH) and the other for $25.5 million Coin USDC, noting that the Lazarus group pocketed these funds using “over 12,000 different crypto addressees to date.” Chainalysis stated the stolen ETH coins were mixed in batches with the popular Tornado Cash mixed service. The sources for this piece include an article in TheHackerNews.
Checking the Status of KernelCare Enterprise Patches Posted on September 22, 2022September 21, 2022 by Joao Correia TuxCare’s KernelCare Enterprise provides live patches for various enterprise-grade Linux distributions. Preparing patches for each new CVE has to account for each of those distributions’ particular quirks and configurations, so the release timing for each may be slightly different. Let’s look at the whole process and how you can follow along with current development. Continue reading “Checking the Status of KernelCare Enterprise Patches”
Bumblebee Malware Offers a new Infection Chain Posted on September 22, 2022September 20, 2022 by Obanla Opeyemi A new version of the Bumblebee malware loader has been discovered by researchers. The new strain of malware offers a new chain of infection, including the use of a PowerScript framework for stealthy reflective injection of a DLL payload into memory. Unlike in the past, when it reached victims via e-mails containing password-protected zipped USO files, the new variant uses a VHD (Virtual Hard Disk) file instead of the ISO file. The new VHD file contains a LNK shortcut file. Instead of running Bumblebee (DLL) directly, the LNK now executes “imageda.ps1,” which starts a PowerShell window and hides it from the user by abusing the ‘ShowWindow’ command. The SP1 script is obfuscated using Base64 and string concatenation to evade AV detection while loading the second stage of the PowerShell loader. For the second stage of the infection, a similar disguise tactic is used as the first. This tactic includes the PowerShell module which is used to load the 64-bit malware into the memory of the PowerShell process through reflective injection. “PowerSploit is an open source post-exploitation framework in which the malware uses a method, Invoke-ReflectivePEInjection, for reflectively loading the DLL into the PowerShell Process. This method validates the embedded file and performs multiple checks to ensure that the file is loaded properly on the executing system,” Cyble explains in the report. The new chain of infection allows Bumblebee to load from memory and never touch the hard drive of the computer, minimizing the chances of being detected and stopped by antivirus tools. Increasing its stealthiness also provides the malware loader with a stronger initial access threat and increases its chances of enticing ransomware and malware operators. The sources for this piece include an article in BleepingComputer.
Hackers Actively Exploit WordPress Zero-day Flaw Posted on September 22, 2022September 20, 2022 by Obanla Opeyemi Wordfence, a WordPress security company, has warned of a zero-day WordPress vulnerability that is now being exploited by attackers. The bug is in a WordPress plugin called BackupBuddy. BackupBuddy is a plugin that allows users to back up their entire WordPress installation from within the dashboard, including theme files, pages, posts, widgets, users, and media files. According to Wordfence, the vulnerability is rooted in the Local Directory copy function, which is designed to store a local copy of the backups. The vulnerability is the product of an insecure implementation that allows attackers to download arbitrary files to the server. “This vulnerability makes it possible for unauthenticated users to download arbitrary files from the affected site which can include sensitive information,” Wordfence said. The bug affecting BackupBuddy is tracked as CVE-3022-31474 and has a severity of 7.5. While the bug affects versions 8.5.8.0 to 8.7.4.1, it was fixed in version 8.7. 5, which was released on September 2, 2022. Wordfence stated that the active exploitation of CVE-2022-31474 began on August 26, 2022. Since then, the platform has been able to block nearly five million attacks, with the majority of intrusions attempting to read files such as /etc/passwd, /wp-config.php,.my.cnf, and .accesshash. Details of the vulnerability remained secret to prevent further exploitation by attackers. “This vulnerability could allow an attacker to view the contents of any file on your server that can be read by your WordPress installation. This could include the WordPress wp-config.php file and, depending on your server setup, sensitive files like /etc/passwd,” said the plugin’s developer, iThemes. BackupBuddy users are advised to upgrade to the latest version to fix the bug and prevent it from being compromised by attackers. Those who are already compromised should reset the database password, change WordPress Salts, and rotate API keys stored in wp-config.php. The sources for this piece include an article in TheHackerNews.
Data Exfil: The New and Darker Version of Ransomware Posted on September 21, 2022September 21, 2022 by Joao Correia Ransomware has become such a common threat over the last few years that companies anticipate coming face to face with an attack at some point. Nonetheless, victims’ lack of adequate preparedness still drives many of the attacks, while the high price of cryptocurrencies added fuel to the fire. Many threat actors worldwide jumped in on the ransomware action, driving rapid growth as companies opened the door to extortion through poor security, lackluster patch management, and backups that just don’t work. While ransomware isn’t going away anytime soon, it is somewhat losing its shine for criminals. This is partly happening because some organizations are getting better at defending their technology assets, and lower crypto valuations have reduced gains. While looking for another opportunity, threat actors have focused on something more dangerous than ransomware: data exfiltration. What could be a bigger threat than encrypting data….? Data exfiltration – or just exfil – is becoming a more common threat. We noticed its growing prevalence emerging earlier this year as we saw attacks at Microsoft, Nvidia, and other large tech firms. Take this year’s attack on Nvidia, for example. Threat group Lapsus$ entangled Nvidia in a complex exchange where the chipmaker was threatened with the public exposure of source code for its proprietary Deep Learning Super Sampling (DLSS) technology. If Nvidia’s code were published publicly, it would substantially undermine the company’s competitive position. And that’s what exfil is all about. Instead of focusing on encrypting data and threatening data loss, exfil attacks are about exposing consequential, private data to the public. The next step is similar to ransomware: the attacker proceeds to extort the victim, threatening to release the data to the public or to sell it to a third party. In fact, Seventy percent of ransomware attacks now involve a threat to leak the data exfiltrated by the ransomware. This was up 43 percent from the previous quarter, confirming that the threat of data exfiltration has rapidly become part of the new ransomware normal. In many cases, exfil is a much bigger threat In the tech sector, proprietary technology is the core competitive advantage. How this technology works – or the source code for it – is incredibly valuable. Competitors accessing trade secrets can completely undermine the company that initially developed the technology. And it’s not even just the proprietary technology itself – it’s confidential business processes, algorithms, conference call recordings… and this is relevant across all industries. It’s not difficult to see those malevolent actors that access this information can pose a genuine, very worrying threat – the threat to take away a company’s competitive advantage. It’s a much more significant danger than ransomware: lost data is lost data and no more. Often this data can be recovered to a degree, and practices are being put in place to reduce the impact of this type of attack. Leaked information, on the other hand, can cause much more damage. There’s a cross-border complicating factor to exfil too. Information exfiltration is increasingly the result of the complex state of the world today. There is a significant demand for the transfer of intellectual property from one country to the next – across competing geopolitical lines. Moreover, some countries might even be “lenient” to local threat actors that focus their attacks on the other side of the geopolitical line. Exfil has another interesting aspect One of the themes driving the information exfiltration game is how malicious actors are increasingly choosing to stay undetected for as long as possible. Cybersecurity teams have been noting this behavior for quite some time – where threat actors linger for a much longer time in a system before revealing their presence. It completely contrasts with past actions that took the approach of a “you’ve been hacked” message flashing across the screen. By taking this approach, the attacker has more time to observe how information flows across a network, doing more intensive reconnaissance – with more opportunities to find the juicy stuff. Quietly lingering for longer allows for more opportunities for harm. Just like ransomware, you can protect yourself against exfil The cybersecurity strategies against ransomware will also guard against exfil extortion – it’s just that organizations are now even more critical to take these measures. Many companies have ransomware protection in place – backup strategies and more finely-grained access to systems and data, for example. These measures still work against ransomware and will be a strong deterrent against attacks driven by information exfiltration. As we’ve suggested many times, that includes one of the most critical parts of cybersecurity risk management: keeping your systems patched consistently because patching closes many easy paths to a successful cyberattack. However, traditional patching that relies on maintenance windows won’t cut it anymore. It’s simply not sufficiently responsive against fast-moving threats. Instead, consider live patching from TuxCare. Our KernelCare Enterprise solution immediately protects your workloads against threats, eliminating the lag caused by maintenance windows – and reducing the opportunity for attackers to find a way in. Learn more about what KernelCare Enterprise can do here.
Attackers use Watering Hole Attacks to Install ScanBox Keylogger Posted on September 21, 2022September 20, 2022 by Obanla Opeyemi A China-based threat actor dubbed APT TA423 is carrying out waterhole attacks on domestic Australian organizations and offshore energy companies in the South China Sea to distribute the ScanBox reconnaissance tool to victims. Waterhole Attack is a cyberattack on a specific organization in which malware is installed on a website that is regularly visited by members of the organization to infect computers used within the organization itself. In order to successfully carry out their malicious activities, the attackers use the ScanBox framework. ScanBox is a customizable and multifunctional Javascript-based framework that is used by adversaries to carry out and convert reconnaissance operations. ScanBox keylogger data from “waterholes” are part of a multi-level attack that gives attackers knowledge of potential targets that will help them launch future attacks against organizations. To execute an attack, the attackers upload the malicious JavaScript to a compromised website where the ScanBox acts as a keylogger, snapping all user-entered activity on the infected website. TA423 launches its attacks with phishing emails pretending to be from an employee of the “Australian Morning News,” a fictitious organization. Targets are then advised to visit their “humble news website.” australianmorningnews[.]com. As soon as the target clicks on the link, they are redirected to a website whose contents are copied from actual news websites, and the malware framework is leaked to them. The primary initial script of a ScanBox keylogger provides a list of information about the target computer, including the operating system, language, and installed version of Adobe Flash. ScanBox also performs an audit for browser extensions, plugins, and components such as WebRTC. The sources for this piece include an article in ThreatPost.
Tech Support
Login
Contact Us