US Space Industry Under Threat from Foreign Cyber Espionage

Read Time:6 Second

An advisory by US intelligence provides guidance for space firms on how to identify an espionage campaign, report and mitigate it

Read More

CVE-2020-28715

Read Time:9 Second

An issue was discovered in kdmserver service in LeEco LeTV X43 version V2401RCN02C080080B04121S, allows attackers to execute arbitrary code, escalate privileges, and cause a denial of service (DoS).

Read More

White House Announces AI Cybersecurity Challenge

Read Time:1 Minute, 6 Second

At Black Hat last week, the White House announced an AI Cyber Challenge. Gizmodo reports:

The new AI cyber challenge (which is being abbreviated “AIxCC”) will have a number of different phases. Interested would-be competitors can now submit their proposals to the Small Business Innovation Research program for evaluation and, eventually, selected teams will participate in a 2024 “qualifying event.” During that event, the top 20 teams will be invited to a semifinal competition at that year’s DEF CON, another large cybersecurity conference, where the field will be further whittled down.

[…]

To secure the top spot in DARPA’s new competition, participants will have to develop security solutions that do some seriously novel stuff. “To win first-place, and a top prize of $4 million, finalists must build a system that can rapidly defend critical infrastructure code from attack,” said Perri Adams, program manager for DARPA’s Information Innovation Office, during a Zoom call with reporters Tuesday. In other words: the government wants software that is capable of identifying and mitigating risks by itself.

This is a great idea. I was a big fan of DARPA’s AI capture-the-flag event in 2016, and am happy to see that DARPA is again inciting research in this area. (China has been doing this every year since 2017.)

Read More

Volatility Workbench: Empowering memory forensics investigations

Read Time:3 Minute, 58 Second

The content of this post is solely the responsibility of the author.  AT&T does not adopt or endorse any of the views, positions, or information provided by the author in this article. 

Memory forensics plays a crucial role in digital investigations, allowing forensic analysts to extract valuable information from a computer’s volatile memory. Two popular tools in this field are Volatility Workbench and Volatility Framework. This article aims to compare and explore these tools, highlighting their features and differences to help investigators choose the right one for their needs.

Volatility Workbench, a powerful tool built on the Volatility Framework, is specifically designed to simplify and enhance the process of memory forensics. This article explores the capabilities of Volatility Workbench, highlighting its importance in uncovering critical evidence and facilitating comprehensive memory analysis.

Understanding Volatility Framework:

Volatility Framework is a robust tool used for memory analysis. It operates through a command-line interface and offers a wide range of commands and plugins. It enables investigators to extract essential data from memory dumps – including running processes, network connections, and passwords. However, it requires technical expertise to utilize effectively.

Volatility introduced people to the power of analyzing the runtime state of a system using the data found in volatile storage (RAM). It also provided a cross-platform, modular, and extensible platform to encourage further work into this exciting area of research. Volatility framework can be downloaded here. The Volativity Foundation provides these tools.

Introducing Volatility Workbench:

Volatility Workbench is a user-friendly graphical interface built on the Volatility Framework. It simplifies memory analysis by providing a visual interface that is more accessible, even for users with limited command-line experience. With Volatility Workbench, investigators can perform memory analysis tasks without the need for extensive command-line knowledge. Volatility Workbench can be downloaded here.

One of the key advantages of Volatility Workbench is its user-friendly interface, designed to simplify the complex process of memory forensics. With its graphical interface, investigators can navigate through various analysis options and settings effortlessly. The tool presents information in a visually appealing manner – with graphs, charts, and timelines, making it easier to interpret and draw insights from extracted data.

The initial interface when the Volatility Workbench is started looks like this:

 

The Volatility Workbench offers options to browse and select memory dump files in formats such as *.bin, *.raw, *.dmp, and *.mem. Once a memory dump file is chosen, the next step is to select the platform or operating system that the system being analyzed is using.

Once the memory image file and platform is selected, click on Get Process List in Volatility Workbench.

It will begin memory scanning. After that, you can use the multiple option in the command tab by selecting a valid command. The description of the command will be available in the dialog box on the side pane.

When the Get Process list is finished, the interface will like this:

Now we can select the command we want to use – let’s try using the command drop down menu.

Voila, we have commands available for analyzing the Windows memory dump.

Let’s try a command which lists process memory ranges that potentially contain injected code.

As seen in image above you can see the command as well as its description. You also have an option to select specific process IDs from the dropdown menu for the processes associated with the findings.

Let’s use the Malfind command to list process memory ranges that potentially contain injected code. It will take some time to process.

The analysis of the Malfind output requires a combination of technical skills, knowledge of malware behavior, and understanding of memory forensics. Continuously updating your knowledge in these areas and leveraging available resources can enhance your ability to effectively analyze the output and identify potential threats within memory dumps.

Look for process names associated with the identified memory regions. Determine if they are familiar or potentially malicious. Cross-reference them with known processes or conduct further research if necessary.

Some of the features of Volatility Workbench:

It streamlines memory forensics workflow by automating tasks and providing pre-configured settings.
It offers comprehensive analysis capabilities, including examining processes, network connections, and recovering artifacts.
It seamlessly integrates with plugins for additional analysis options and features.
It lets you generate comprehensive reports for documentation and collaboration.

Conclusion

By leveraging the capabilities of the underlying Volatility Framework, Volatility Workbench provides a streamlined workflow, comprehensive analysis options, and flexibility through plugin integration. With its user-friendly interface, investigators can efficiently extract valuable evidence from memory dumps, uncover hidden activities, and contribute to successful digital investigations. Volatility Workbench is an indispensable tool in the field of memory forensics, enabling investigators to unravel the secrets stored within a computer’s volatile memory.

Read More

CVE-2022-46751

Read Time:1 Minute, 2 Second

Improper Restriction of XML External Entity Reference, XML Injection (aka Blind XPath Injection) vulnerability in Apache Software Foundation Apache Ivy.This issue affects any version of Apache Ivy prior to 2.5.2.

When Apache Ivy prior to 2.5.2 parses XML files – either its own configuration, Ivy files or Apache Maven POMs – it will allow downloading external document type definitions and expand any entity references contained therein when used.

This can be used to exfiltrate data, access resources only the machine running Ivy has access to or disturb the execution of Ivy in different ways.

Starting with Ivy 2.5.2 DTD processing is disabled by default except when parsing Maven POMs where the default is to allow DTD processing but only to include a DTD snippet shipping with Ivy that is needed to deal with existing Maven POMs that are not valid XML files but are nevertheless accepted by Maven. Access can be be made more lenient via newly introduced system properties where needed.

Users of Ivy prior to version 2.5.2 can use Java system properties to restrict processing of external DTDs, see the section about “JAXP Properties for External Access restrictions” inside Oracle’s “Java API for XML Processing (JAXP) Security Guide”.

Read More

USN-6302-1: Vim vulnerabilities

Read Time:1 Minute, 36 Second

It was discovered that Vim incorrectly handled memory when opening certain
files. If an attacker could trick a user into opening a specially crafted
file, it could cause Vim to crash, or possibly execute arbitrary code. This
issue only affected Ubuntu 22.04 LTS. (CVE-2022-2522, CVE-2022-2580,
CVE-2022-2817, CVE-2022-2819, CVE-2022-2862, CVE-2022-2889, CVE-2022-2982,
CVE-2022-3134)

It was discovered that Vim did not properly perform bounds checks in the
diff mode in certain situations. An attacker could possibly use this issue
to cause a denial of service. This issue only affected Ubuntu 18.04 LTS,
Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-2598)

It was discovered that Vim did not properly perform bounds checks in
certain situations. An attacker could possibly use this issue to cause a
denial of service. This issue only affected Ubuntu 22.04 LTS.
(CVE-2022-2816)

It was discovered that Vim incorrectly handled memory when skipping
compiled code. An attacker could possibly use this issue to cause a denial
of service. This issue only affected Ubuntu 22.04 LTS. (CVE-2022-2874)

It was discovered that Vim incorrectly handled memory when opening certain
files. If an attacker could trick a user into opening a specially crafted
file, it could cause Vim to crash, or possibly execute arbitrary code. This
issue only affected Ubuntu 20.04 LTS and Ubuntu 22.04 LTS. (CVE-2022-3016,
CVE-2022-3037)

It was discovered that Vim incorrectly handled memory when invalid line
number on “:for” is ignored. An attacker could possibly use this issue to
cause a denial of service. (CVE-2022-3099)

It was discovered that Vim incorrectly handled memory when passing invalid
arguments to the assert_fails() method. An attacker could possibly use this
issue to cause a denial of service. This issue only affected Ubuntu 22.04
LTS. (CVE-2022-3153)

Read More