Microsoft this week announced the open source availability of Python code for “CyberBattleSim,” a research toolkit that supports simulating complex computer systems.

Designed to help advance artificial intelligence and machine learning, the experimental research project was designed to aid in the analysis of how “autonomous agents operate in a simulated enterprise environment using high-level abstraction of computer networks and cybersecurity concepts.”

CyberBattleSim allows for the training of automated agents, and provides a Python-based OpenAI Gym interface for that. In the simulated environments, defenders can leverage reinforcement learning algorithms and set up various cybersecurity challenges.

Reinforcement learning, Microsoft explains, is a type of machine learning that teaches autonomous agents to make decisions based on the interaction with the environment: agents improve strategies through repeated experience, similarly to playing a video game over and over to become better at it.

[ Related: Microsoft, MITRE Release Adversarial ML Threat Matrix ]

In software security, reinforcement learning involves the use of agents that play the role of attackers and defenders, and the analysis of their evolution in the simulated environment. The attacker seeks to steal information, while the attacker focuses on blocking the attacker or mitigating their actions.

CyberBattleSim employs OpenAI Gym for building interactive environments, and focuses on the lateral movement phase of a cyber-attack. The project simulates a fixed network with predefined vulnerabilities that the attacker model can exploit for lateral movement, while a defender agent seeks to detect the attacker and contain the intrusion.

“The simulation Gym environment is parameterized by the definition of the network layout, the list of supported vulnerabilities, and the nodes where they are planted. The simulation does not support machine code execution, and thus no security exploit actually takes place in it,” Microsoft explains.

The simulated computer network consists of systems running multiple platforms and aims to illustrate how the use of the latest operating systems and keeping them updated can deliver improved protections. Using the Gym interface, defenders can instantiate automated agents and then analyze their evolution in the environment.

“To perform well, agents now must learn from observations that are not specific to the instance they are interacting with. They cannot just remember node indices or any other value related to the network size. They can instead observe temporal features or machine properties,” the tech giant explains.

Microsoft says CyberBattleSim has a highly abstract nature and cannot be applied to real-world systems, which provides protection against the nefarious use of the trained automated agents.

Related: It’s Time For Machine Learning to Prove Its Own Hype

Related: Machine Learning & Security: Making Users Part of the Equation

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/dgR98_1Ambk/microsoft-open-sources-cyberbattlesim-enterprise-environment-simulator

The U.S. Department of Homeland Security’s Cybersecurity and Infrastructure Security Agency (CISA) has released a new tool to help with the detection of potential compromise within Microsoft Azure and Microsoft 365 environments.

Dubbed Aviary, the new tool is a dashboard that makes it easy to visualize and analyze output from Sparrow, the compromise detection tool that was released in December 2020.

Built by CISA to help with the detection of malicious activity related to SolarWinds compromise, Sparrow can be used by network defenders to hunt for potential malicious activity within Microsoft Azure Active Directory (AD), Microsoft 365 (M365), and Office 365 (O365) environments.

Sparrow was designed to help identify both accounts and applications that might have been compromised within an organization’s Azure/M365 environment.

With Sparrow, defenders can look out for domain authentication or federation modifications, find new and modified credentials in logs, detect privilege escalation, detect OAuth consent and users’ consent to applications, identify anomalous SAML token sign-ins, and check the Graph API application permissions for service principals and apps in the environment, among others.

A Splunk-based dashboard, the newly released Aviary is meant to facilitate the analysis of output data from Sparrow.

The tool is now available on GitHub, with additional information on how to install Aviary, after running Sparrow, included in CISA’s January announcement for the detection tool, which has been updated this week with instructions on using Aviary.

Related: Reinventing Managed Security Services’ Detection and Response

Related: The Crucial Component of Detection and Response: Intelligence Pivoting

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/1oWbCjE6M94/cisa-releases-tool-detect-microsoft-365-compromise

A newly discovered cryptomining worm is stepping up its targeting of Windows and Linux devices with a batch of new exploits and capabilities, a researcher said.

Research company Juniper started monitoring what it’s calling the Sysrv botnet in December. One of the botnet’s malware components was a worm that spread from one vulnerable device to another without requiring any user action. It did this by scanning the Internet for vulnerable devices and, when found, infecting them using a list of exploits that has increased over time.

The malware also included a cryptominer that uses infected devices to create the Monero digital currency. There was a separate binary file for each component.

Constantly growing arsenal

By March, Sysrv developers had redesigned the malware to combine the worm and miner into a single binary. They also gave the script that loads the malware the ability to add SSH keys, most likely as a way to make it better able to survive reboots and to have more sophisticated capabilities. The worm was exploiting six vulnerabilities in software and frameworks used in enterprises, including Mongo Express, XXL-Job, XML-RPC, Saltstack, ThinkPHP, and Drupal Ajax.

“Based on the binaries we have seen and the time when we have seen them, we found that the threat actor is constantly updating its exploit arsenal,” Juniper researcher Paul Kimayong said in a Thursday blog post.

Thursday’s post listed more than a dozen exploits that are under attack by the malware. They are:

The exploits Juniper Research previously saw the malware using are:

• Mongo Express RCE (CVE-2019-10758)
• XXL-JOB Unauth RCE
• XML-RPC (CVE-2017-11610)
• CVE-2020-16846 (Saltstack RCE)
• ThinkPHP RCE
• CVE-2018-7600 (Drupal Ajax RCE)

Come on in, water’s great

The developers have also changed the mining pools infected devices join. The miner is a version of the open source XMRig that currently mines for the following mining pools:

• Xmr-eu1.nanopool.org:14444
• f2pool.com:13531
• minexmr.com:5555

A mining pool is a group of cryptocurrency miners who combine their computational resources to reduce the volatility of their returns and increase the chances of finding a block of transactions. According to mining pool profitability comparison site PoolWatch.io, the pools used by Sysrv are three of the four top Monero mining pools.

“Combined together, they almost have 50% of the network hash rate,” Kimayong wrote. “The threat actor’s criteria appears to be top mining pools with high reward rates.”

The profit from mining is deposited into the following wallet address:

49dnvYkWkZNPrDj3KF8fR1BHLBfiVArU6Hu61N9gtrZWgbRptntwht5JUrXX1ZeofwPwC6fXNxPZfGjNEChXttwWE3WGURa

Nanopool shows that the wallet gained 8 XMR, worth roughly $1,700 USD, from March 1 to March 28. It’s adding about 1 XMR every two days.

A threat to Windows and Linux alike

The Sysrv binary is a 64-bit Go binary that’s packed with the open source UPX executable packer. There are versions for both Windows and Linux. Two Windows binaries chosen at random were detected by 33 and 48 of the top 70 malware protection services, according to VirusTotal. Two randomly picked Linux binaries had six and nine.

The threat from this botnet isn’t just the strain on computing resources and the non-trivial drain of electricity. Malware that has the ability to run a cryptominer almost certainly can also install ransomware and other malicious wares. Thursday’s blog post has dozens of indicators that administrators can use to see if the devices they manage are infected.

https://arstechnica.com/?p=1755573

The Pwn2Own 2021 hacking competition has come to an end, with participants earning more than $1.2 million — more than ever paid out at the event — for exploits in the browser, virtualization, server, local privilege escalation, and enterprise communications categories.

Over the course of three days, participants made 23 attempts, targeting Safari, Chrome, Edge, Windows 10, Ubuntu, Microsoft Teams, Zoom, Parallels, Oracle VirtualBox, and Microsoft Exchange. Oracle VirtualBox was only targeted by one team and their attempt failed. The other products were all hacked by at least one team.

The highest rewards were paid out to team Devcore for an Exchange server exploit, a researcher named OV for a Microsoft Teams exploit, and Daan Keuper and Thijs Alkemade from Computest for a zero-click Zoom exploit. They each earned $200,000 for their work and each of them earned the same number of points in total, meaning they all shared the first place.

Zoom told SecurityWeek that it has already started working on a patch and provided some clarifications regarding exploitation and impacted products.

“We are working to mitigate this issue with respect to Zoom Chat, our group messaging product. In-session chat in Zoom Meetings and Zoom Video Webinars are not impacted by the issue. The attack must also originate from an accepted external contact or be a part of the target’s same organizational account. As a best practice, Zoom recommends that all users only accept contact requests from individuals they know and trust,” explained a Zoom spokesperson.

Significant rewards were also earned by Jack Dates from RET2 Systems ($100,000 for a Safari hack), and Bruno Keith and Niklas Baumstark of Dataflow Security ($100,000 for an exploit that works on both Edge and Chrome).

There were also several successful privilege escalation attempts on Windows 10 and virtual machine escapes on Parallels, each of them earning participants $40,000. Several Ubuntu privilege escalation exploits were rewarded with $30,000 each.

According to Trend Micro’s Zero Day Initiative (ZDI), which organizes Pwn2Own, participants took home $1,210,000 of the $1.5 million prize pool, more than in any other previous year. In comparison, in 2020, participants only earned $270,000 for their exploits. In 2019, prizes totaled $545,000.

Related: White Hats Earn $440,000 for Hacking Microsoft Products on First Day of Pwn2Own 2021

Related: $200,000 Awarded for Zero-Click Zoom Exploit at Pwn2Own

Related: Researchers Earn $280,000 for Hacking Industrial Systems at Pwn2Own Miami

Related: Routers, NAS Devices, TVs Hacked at Pwn2Own Tokyo 2020

Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/SdYsfZbGBgo/pwn2own-2021-participants-earn-over-12-million-their-exploits

Cisco this week announced patches for tens of vulnerabilities across its product portfolio, including a critical severity issue impacting the SD-WAN vManage software.

Tracked as CVE-2021-1479 with a CVSS score of 9.8, the critical bug exists because of improper validation of user-supplied input and could allow an attacker to trigger a buffer overflow by sending a crafted connection request to the remote management component of SD-WAN vManage.

An attacker able to successfully exploit the security issue would “execute arbitrary code on the underlying operating system with root privileges,” Cisco explains.

The flaw was addressed alongside two high severity elevation of privilege vulnerabilities in SD-WAN vManage, each featuring a CVSS score of 7.8.

Exploitable by authenticated attackers, the bugs could allow for the escalation of privileges to root.

In an advisory, Cisco notes that affected products include IOS XE SD-WAN software, SD-WAN cEdge routers, SD-WAN vBond Orchestrator software, SD-WAN vEdge routers, and SD-WAN vSmart Controller software.

The company has released software updates to address these flaws and says that there are no workarounds available. Cisco also notes that it is not aware of the flaws being exploited in the wild.

Separately, Cisco announced that it would not release patches for a critical

vulnerability in the web-based management interface of RV110W, RV130, RV130W, and RV215W small business routers, which reached end-of-life.

Tracked as CVE-2021-1459 and triggered through crafted HTTP requests, the vulnerability could be exploited to execute arbitrary code with root privileges. The vulnerability affects RV110W Wireless-N VPN firewall, RV130 VPN router, RV130W Wireless-N multifunction VPN router, and RV215W Wireless-N VPN router.

“Cisco has not released and will not release software updates to address the vulnerability described in this advisory. The Cisco Small Business RV110W, RV130, RV130W, and RV215W Routers have entered the end-of-life process,” the company announced.

Several high severity vulnerabilities that the tech giant patched in its Small Business RV series routers could be exploited to execute arbitrary commands, execute code, leak memory, or cause denial of service conditions. Other high risk flaws were patched in Unified Communications Manager (Unified CM) and Advanced Malware Protection (AMP) for Endpoints Windows Connector, ClamAV for Windows, and Immunet.

Cisco also published advisories to detail medium severity flaws patched in IOS XR software, Webex Meetings for Android, Webex Meetings, Cisco Umbrella, Dual WAN Gigabit VPN routers, Unified Intelligence Center software, Unified CM and Unified CM SME.

Details on each of the addressed vulnerability can be found on Cisco’s support

website.

Related: Cisco Products Exposed to DoS Attacks Due to Snort Vulnerability

Related: Cisco Patches Severe Flaws in Network Management Products

Related: Vulnerabilities Will Remain Unpatched in EOL Cisco Routers

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/6UCHfzxFurs/cisco-patches-critical-flaw-sd-wan-vmanage

NEWS ANALYSIS: Google’s decision to promote Rust for low-level Android programming is another sign that the shelf-life for memory corruption mitigations are no match for the speed of in-the-wild exploit development.

Just 13 years after Google introduced the sandbox in Chrome touting “a new approach in browser security,” the company is now blaming the limitations — and high processing cost — of sandboxing for a new decision to promote Rust as the low-level programming language of choice for the Android operating system.

The decision to promote Rust over C and C++ isn’t exactly a surprise but the language used in Google’s announcement signals a sad end to the sandbox as an effective anti-exploit mitigation for a vexing problem haunting software engineering since the mid-1990s.

“Sandboxing is expensive,” says Jeff Vander Stoep, a member of Google’s Android team. “Sandboxing doesn’t eliminate vulnerabilities from the code and its efficacy is reduced by high bug density, allowing attackers to chain multiple vulnerabilities together,” he added.

He said Google is turning to memory-safe languages like Rust to help overcome these “limitations” by lowering the density of bugs in the Android code and increasing the effectiveness of the existing sandbox.

More importantly, Vander Stoep says the move reduces Google’s sandboxing needs entirely and enables the creation and introduction of new software features that are both safer and lighter on resources.

HIGH SEVERITY 

He said memory safety problems in C and C++ continue to be the “most-difficult-to-address” issue in modern software engineering and noted that the Android team — like the rest of the tech industry — spent heavily to mitigate a class of vulnerabilities without much success.

“In spite of these efforts [to detect, fix and mitigate these issues], memory safety bugs continue to be a top contributor of stability issues, and consistently represent more than 70 percent  of Android’s high severity security vulnerabilities,” Vander Stoep added.

The problem isn’t limited to Android.  Published data from Google Project Zero shows that the majority of in-the-wild zero-day attacks over the last few years are dominated by buffer overflows and use-after-free memory corruption issues.

Ever since the mid-1990s, the brightest minds in cybersecurity have attempted to find approaches to solve memory corruption issues.  These long-term, cross-industry efforts produced many exciting mitigations and effectively raised the cost for attackers.

However, these mitigations came with heavy costs and the shelf-life for things like sandboxing has gotten shorter and shorter as attackers quickly found ways to bypass these roadblocks.

CAT AND MOUSE

“It’s a cat-and-mouse we can’t win,” says an ex-Google software engineer who requested anonymity. “We spend a lot on these mitigations. We spend a lot to address CPU performance hits, we spend a ton more on software development costs and, poof, someone comes up with a bypass and it feels like we’re back to square one.”

“Should we really have spent so much on sandboxing?  Should we really have spent so much all the control-flow integrity mitigations that didn’t really move the bar?  I’m not sure this was money and resources well spent,” he said in exasperation.

Despite these frustrations, the sandbox has been an effective mitigation that made it very difficult to exploit software programs.  Prior to the popularity of sandboxing, attackers could simply exploit a single buffer overflow vulnerability to achieve remote code execution, the holy grail of attacks.

Once sandboxes became a key feature in browsers and desktop apps, the cost of a remote code execution exploit was raised. Where a single bug won the Pwn2Own contest 10 years ago, attackers today must chain exploits for multiple vulnerabilities and include an expensive “sandbox escape” to achieve full code execution.

Now, there’s a shift to using memory-safe languages to effectively eliminate memory corruption as a bug class. For example, on the Android OS, managed languages like Java and Kotlin have become the go-to choice for app development because of ease of use, portability, and safety.  In addition, the Android Runtime (ART) manages memory on behalf of the developer.

The Android OS uses Java extensively, effectively protecting large portions of the Android platform from memory corruption bugs. However, Java and Kotlin are not options for lower layers of the operating system, as Google explains here:

Lower levels of the OS require systems programming languages like C, C++, and Rust. These languages are designed with control and predictability as goals. They provide access to low level system resources and hardware. They are light on resources and have more predictable performance characteristics.

For C and C++, the developer is responsible for managing memory lifetime. Unfortunately, it’s easy to make mistakes when doing this, especially in complex and multithreaded codebases.

Rust provides memory safety guarantees by using a combination of compile-time checks to enforce object lifetime/ownership and runtime checks to ensure that memory accesses are valid. This safety is achieved while providing equivalent performance to C and C++.

Google describes the addition of a new language to the Android platform is a large undertaking and warned that there are toolchains and dependencies that need to be maintained, test infrastructure and tooling that must be updated, and developers that need to be trained. “Scaling this to more of the OS is a multi-year project,” the company said.

NO SILVER BULLET

Still, security experts warn that moving to Rust isn’t going to solve all memory lifetime issues.

“Certain patterns just turn them into application logic bugs vs. RCE. An improvement, but no silver bullet,” says Halvar Flake, a security industry pioneer who has worked on memory corruption mitigations.

On a recent podcast interview, head of privacy and security at Lyft Nico Waisman also discussed the shift to memory-safe languages and predicted a future of app logic bugs and a continued dependence on C and C++ code in legacy software products.

Memory safety issues will continue to haunt the security landscape for decades to come but there is optimism that a combination of new technology — especially around memory tagging — and the adoption of safer programming languages will point to a brighter future.

But, as history has shown, mitigations have a shelf-life and novel techniques and bypasses are always just a Black Hat presentation away.  The sandbox was effective and it made life more difficult for attackers but, as Google’s decision shows, there’s a hefty price tag and no signs that sandbox-bypass exploits are going away.

The sandbox had a good run but it’s time to acknowledge this mitigation has seen its time in the sun.

Ryan Naraine is Editor-at-Large at SecurityWeek and host of the popular Security Conversations podcast series. Ryan is a journalist and cybersecurity strategist with more than 20 years experience covering IT security and technology trends. He is a regular speaker at cybersecurity conferences around the world.
Ryan has built security engagement programs at major global brands, including Intel Corp., Bishop Fox and Kaspersky GReAT. He is a co-founder of Threatpost and the global SAS conference series. Ryan’s career as a journalist includes bylines at major technology publications including Ziff Davis eWEEK, CBS Interactive’s ZDNet, PCMag and PC World.
Follow Ryan on Twitter @ryanaraine.

Previous Columns by Ryan Naraine:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/w3Q6T2GCDbU/cost-sandboxing-prompts-shift-memory-safe-languages-little-too-late

It’s a bigger problem than is immediately apparent, and has the potential for hacks as big as Equifax and as widespread as SolarWinds.

The universal need for speed and lack of resource in commercial app development requires developers to use free open-source software libraries. The difficulty is that there is no easy way to manage the open-source vulnerabilities that get included via the libraries into the finished commercial app.

The size of this problem has been analyzed in the new Contrast Labs 2021 Open-Source Security Report. The study looked at tens of thousands of real-world applications and APIs from Contrast’s own telemetry – and found a potentially serious problem.

First of all, the average application contains 118 open-source libraries. Many of these contain vulnerabilities, but many of the vulnerabilities afford no risk since only 38 percent of the libraries included in an app are actually used by the app.

Inside the library, the vulnerability may be found in just one class. However, in Java libraries, for instance, only 32 percent of the classes contained are invoked by the application. It is more than possible, then, that the finished app uses a library containing a known vulnerability that is of zero risk.

This is complicated by ‘transitive dependencies’, where a function consciously required from one library might actually rely on different additional libraries – which may inadvertently, and possibly unknowingly, be called and included in the shipped app.

DOWNSTREAM ISSUES

The result is that under-resourced teams need to manage vulnerabilities that may or may not be relevant within hundreds of libraries, possibly within many different apps, and always with the possibility that library updates may cause further downstream issues.

Teams have a choice between spending many precious hours determining whether their apps contain a library that needs to be updated and then updating it, or just as likely, simply ignoring the problem. The latter course seems to be quite popular, since the average library in use is 2.5 years old, and 6 percent are more than five years old.

Static Code Analysis (SCA) engines exist that can return a list of CVEs found in applications. Such legacy tools do not, however, differentiate between vulnerabilities in active and inactive libraries. Contrast’s study shows that 17 percent of Critical and Major CVEs in Java applications, 15 percent in .NET applications, and 80 percent in Node applications are in inactive libraries or classes. SCA tends to provide a high number of false positives in the search for active vulnerabilities, increasing the pressure on development teams to ignore the problem and not apply the update.

But the report (PDF) warns that aging libraries merely magnify problems for the future:

“Failure to keep libraries updated over time not only increases risk to an organization but also makes library updates much more difficult and time-consuming when they are finally done. When a library stays dormant in an application for multiple years, any new vulnerability is difficult to fix because so much code has been built over it.”

“It’s a devil’s bargain,” Contrast’s co-founder and CTO Jeff Williams told SecurityWeek, “because the farther you get behind, the harder it is to get back up to date. So, you accrue technical debt if you don’t keep your libraries patched. But commercial companies are focused on rolling out new features and they don’t want to do those library updates if they don’t absolutely have to.”

“It’s a big problem,” he added. “All of the apps we now love and depend on – online banking, shopping, healthcare, defense, government and so on – use these libraries. If a library contains a vulnerability and is used by the app, that vulnerability becomes part of the app and can be attacked.”

PRIMARY ROUTES FOR ATTACKERS

The Equifax breach of 2017 is the iconic example. The breach was achieved via an Apache licensed library called Object Graph Navigation language (OGNL) by exploiting a defect related to OGNL parsing error messages.

Open-source libraries offer two primary routes for attackers. The first is via a discovered vulnerability as in the Equifax breach, while the second is by introducing a vulnerability into the library source. The potential harm that could be caused by the second method is massive.

A huge problem is that there is no centralized order to open source. Anybody can create a new library and make it available – usually from one of many open-source repositories – from where it can be downloaded by anyone. Other coders can add to the original. If an attacker can introduce a vulnerability at this stage, it can be included in all the apps that use the library.

This can be many. The top 25 Node libraries are present in more than 90 percent of Node-using apps. This is not necessarily as dangerous as it may seem since many of the libraries are inactive within the apps – but nevertheless the most common active library is used in 42 percent of apps. A vulnerability introduced into this library – or merely discovered within it – will be included in all apps using the library making all the companies using the finished product vulnerable. This scenario is repeated to a lesser or greater degree within all categories of library.

Part of the problem caused by the lack of an overall controlling body is there is no simple way to track vulnerabilities and library updates. “There is no formal notification system,” said Williams. “You have to run some kind of tool that can identify all your libraries and then check them against a database and see if any of them are out of date or have a known vulnerability. That’ll give you a task list of things that you need to go update;” bearing in mind that the task list may still include a high number of false positives where your apps and your use of the libraries are not affected by the vulnerabilities.

COPYLEFT LIBRARIES

There is still another complexity to add to the difficulty in securely managing open-source libraries – the existence of what is commonly known as ‘copyleft’ libraries. While most open-source software can be freely used, some have some form of copyright left within them. “In most cases,” explained Williams, “this merely requires that the copyright of the developers be acknowledged. But some – like those using the GPL license – go further. Under GPL, if you use the library you have to make the resultant code also open-source under the same terms.”

This means that you must make your own code free to use– which is somewhat incompatible with commercial software. “The guy that created it had a very sort of, utopian vision of how code should be free, and everyone should share, and if we all work together then this code will benefit humanity. But most companies aren’t comfortable with that. They don’t want to make the code they may be developing under a contract for another company publicly available. And so, lawyers are nervous about any code that has a GPL license coming into their organization.”

Strictly speaking, there is nothing incredibly difficult about managing vulnerabilities in the open-source supply chain. The problem is that it requires more man hours than most companies can provide, or better automation than most solutions deliver. The result is the problem is often ignored or only partially dealt with. Williams’ purpose is to shine a light on the whole issue, “so that companies can focus on what matters, and hopefully make smarter library decisions and keep us all a little safer.”

Related: Critical Vulnerability Addressed in Popular Code Libraries

Related: Framework Isolates Libraries in Firefox to Improve Security

Related: GitHub Security Alerts Lead to Fewer Vulnerable Code Libraries

Related: Hackers Target Two Unpatched Flaws in Windows Adobe Type Manager Library

Kevin Townsend is a Senior Contributor at SecurityWeek. He has been writing about high tech issues since before the birth of Microsoft. For the last 15 years he has specialized in information security; and has had many thousands of articles published in dozens of different magazines – from The Times and the Financial Times to current and long-gone computer magazines.

Previous Columns by Kevin Townsend:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/zhkWu5KOBMo/library-dependencies-and-open-source-supply-chain-nightmare

Ransomware operators shut down two production facilities belonging to a European manufacturer after deploying a relatively new strain that encrypted servers that control a manufacturer’s industrial processes, a researcher from Kaspersky Lab said on Wednesday.

The ransomware, known as Cring, came to public attention in a January blog post. It takes hold of networks by exploiting long-patched vulnerabilities in VPNs sold by Fortinet. Tracked as CVE-2018-13379, the directory transversal vulnerability allows unauthenticated attackers to obtain a session file that contains the username and plaintext password for the VPN.

With an initial toehold, a live Cring operator performs reconnaissance and uses a customized version of the Mimikatz tool in an attempt to extract domain administrator credentials stored in server memory. Eventually, the attackers use the Cobalt Strike framework to install Cring. To mask the attack in progress, the hackers disguise the installation files as security software from Kaspersky Lab or other providers.

Once installed, the ransomware locks up data using 256-bit AES encryption and encrypts the key using an RSA-8192 public key hardcoded into the ransomware. A note left behind demands two bitcoins in exchange for the AES key that will unlock the data.

More bang for the buck

In the first quarter of this year, Cring infected an unnamed manufacturer in Germany, Vyacheslav Kopeytsev, a member of Kaspersky Lab’s ICS CERT team said in an email. The infection spread to a server hosting databases that were required for the manufacturer’s production line. As a result, processes were temporarily shut down inside two Italy-based facilities operated by the manufacturer. Kaspersky Lab believes the shutdowns lasted two days.

“Various details of the attack indicate that the attackers had carefully analyzed the infrastructure of the attacked organization and prepared their own infrastructure and toolset based on the information collected at the reconnaissance stage,” Kopeytsev wrote in a blog post. He went on to say, “An analysis of the attackers’ activity demonstrates that, based on the results of reconnaissance performed on the attacked organization’s network, they chose to encrypt those servers the loss of which the attackers believed would cause the greatest damage to the enterprise’s operations.”

Incident responders eventually restored most but not all of the encrypted data from backups. The victim didn’t pay any ransom. There are no reports of the infections causing harm or unsafe conditions.

Sage advice not heeded

In 2019, researchers observed hackers actively trying to exploit the critical FortiGate VPN vulnerability. Roughly 480,000 devices were connected to the Internet at the time. Last week, the FBI and Cybersecurity and Infrastructure Security agency said CVE-2018-13379 was one of several FortiGate VPN vulnerabilities that were likely under active exploit for use in future attacks.

Fortinet in November said that it detected a “large number” of VPN devices that remained unpatched against CVE-2018-13379. The advisory also said that company officials were aware of reports that the IP addresses of those systems were being sold in underground criminal forums or that people were performing Internet-wide scans to find unpatched systems themselves.

Besides failing to install updates, Kopeytsev said the Germany-based manufacturer also neglected to install antivirus updates and to restrict access to sensitive systems to only select employees.

It’s not the first time a manufacturing process has been disrupted by malware. In 2019 and again last year Honda halted manufacturing after being infected by the WannaCry ransomware and an unknown piece of malware. One of the world’s biggest producers of aluminum, Norsk Hydro of Norway, was hit by a ransomware attack in 2019 that shut down its worldwide network, stopped or disrupted plants, and sent IT workers scrambling to return operations to normal.

Patching and reconfiguring devices in industrial settings can be especially costly and difficult because many of them require constant operation to maintain profitability and to stay on schedule. Shutting down an assembly line to install and test a security update or to make changes to a network can lead to real-world expenses that are nontrivial. Of course, having ransomware operators shut down an industrial process on their own is an even more dire scenario.

https://arstechnica.com/?p=1755297

The April 2021 Android security bulletin published this week by Google describes more than 30 vulnerabilities in the mobile operating system, including a remote code execution flaw in the System component.

Tracked as CVE-2021-0430 and affecting Android 10 and 11, the code execution vulnerability is deemed critical severity. The bug was patched as part of the 2021-04-01 security patch level.

“The most severe of these issues is a critical security vulnerability in the System component that could enable a remote attacker using a specially crafted file to execute arbitrary code within the context of a privileged process,” Google explains in its advisory.

Five other vulnerabilities were addressed in the System component: three elevation of privilege and two information disclosure issues. All of these feature a severity rating of high.

The 2021-04-01 security patch level also brings patches for 12 other high-severity vulnerabilities: nine in the Framework component (seven elevation of privilege and two information disclosure bugs), and three in the Media framework (one elevation of privilege and two information disclosure issues).

The second part of this month’s set of patches, which arrives on devices as the 2021-04-05 security patch level, includes fixes for 18 vulnerabilities, in System (two high-severity bugs), Kernel components (two high-severity flaws), MediaTek components (one high-severity issue), Qualcomm components (one high-severity bug), and Qualcomm closed-source components (one critical and 11 high-severity vulnerabilities).

This week, Google also announced new security patches for Pixel devices, which include fixes for three vulnerabilities in Framework (two elevation of privilege flaws) and Qualcomm components. All three feature severity ratings of moderate.

Devices running a security patch level of 2021-04-05 or later have fixes for all of the issues associated with this security patch level, as well as with previous patch levels. On Pixel devices, a security patch level of 2021-04-05 addresses all vulnerabilities in the April 2021 and previous Pixel security bulletins as well.

Related: Recently Patched Android Vulnerability Exploited in Attacks

Related: Google Patches Critical Remote Code Execution Vulnerability in Android

Related: Google Patches Over a Dozen High-Severity Privilege Escalation Flaws in Android

Ionut Arghire is an international correspondent for SecurityWeek.

Previous Columns by Ionut Arghire:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/gsoHOGsJEC0/google-patches-critical-code-execution-vulnerability-android

On the first day of the Pwn2Own 2021 hacking competition, participants earned more than half a million dollars, including $440,000 for demonstrating exploits against Microsoft products.

The competition’s organizer, Trend Micro’s Zero Day Initiative (ZDI), said there were seven attempts on the first day and five of them were successful.

A team called Devcore earned $200,000 for taking complete control of a Microsoft Exchange server by chaining authentication bypass and local privilege escalation vulnerabilities.

A researcher who uses the online moniker OV was awarded $200,000 for a Microsoft Teams code execution exploit.

Another significant reward went to Jack Dates from RET2 Systems, who earned $100,000 for a kernel-level code execution exploit in Apple’s Safari web browser. The exploit leveraged an integer overflow and an out-of-bounds write bug.

Also on the first day, Team Viettel earned $40,000 for a local privilege escalation vulnerability in Windows 10, and Ryota Shiga of Flatt Security earned $30,000 for a privilege escalation flaw in Ubuntu Desktop.

Participants also attempted to hack the Parallels Desktop and Oracle VirtualBox virtualization products, but they failed to demonstrate their exploits within the allotted time.

On the second and third days of Pwn2Own 2021, white hat hackers will attempt to demonstrate exploits against Chrome and Edge, Zoom, Parallels Desktop, Microsoft Exchange, Ubuntu, and Windows 10.

There is also an automotive category this year for hacking Tesla cars. Participants have been offered up to $600,000 and a vehicle, but it seems no one has signed up for this category. A team of researchers did earn a Tesla back in 2019 when the automotive hacking category was introduced at Pwn2Own. In 2020, contestants didn’t have the opportunity to hack a Tesla due to the coronavirus pandemic.

The prize pool for Pwn2Own 2021 exceeds $1.5 million in cash and other prizes. At last year’s event, participants only earned $270,000 for their exploits.

Related: Researchers Earn $280,000 for Hacking Industrial Systems at Pwn2Own Miami

Related: Routers, NAS Devices, TVs Hacked at Pwn2Own Tokyo 2020

Related: NETGEAR Router, WD NAS Device Hacked on First Day of Pwn2Own Tokyo 2020

Related: Researchers Hack Windows, Ubuntu, macOS at Pwn2Own 2020

Eduard Kovacs (@EduardKovacs) is a contributing editor at SecurityWeek. He worked as a high school IT teacher for two years before starting a career in journalism as Softpedia’s security news reporter. Eduard holds a bachelor’s degree in industrial informatics and a master’s degree in computer techniques applied in electrical engineering.

Previous Columns by Eduard Kovacs:

Tags:

http://feedproxy.google.com/~r/Securityweek/~3/SRv8lEO0qJY/white-hats-earn-440000-hacking-microsoft-products-first-day-pwn2own-2021