Jeff's Blog

A SQL injection vulnerability has been identified in the web API endpoint located at https://<coreserver>/landesk/managementsuite/core/provisioning.secure/ProvisioningSecure.asmx.

This vulnerability is present within the Provisioning.Secure.dll utilized by this API endpoint. If we decompile this DLL, the vulnerability can be clearly seen within 2 methods.

This…

Multiple cryptographic vulnerabilities have been identified in the web API endpoint at http://<coreserver>/landesk/managementsuite/core/cmp.secure. These vulnerabilities compromise the at-rest security model of all data protected by this module, and could lead to unauthorized device decryption, credential disclosure, and full managed endpoint compromise.

This API endpoint is used for encryption of such sensitive information as filevault credentials, administrative override credentials, Windows credent…

By design, multiple directories on the LDMS core server are wide-open and globally readable via HTTP. For example, see the following web locations available on an LDMS core server:

• https://<coreserver>/ldlogon
• https://<coreserver>/upl
• https://<coreserver/landesk

While this is by design, it is a major architectural oversight. This design played an instrumental role in the discovery of many of these vulnerabilities, and allows for information disclosure and arbitrary code execution when paired wit…

During an imaging task, the LANDesk provisioning subsystem creates a copy of each injected file in the globally readable network share \\<coreserver>\ldlogon\provisioning\config. This share is created during the LANDesk Management Core Server installation process, and the installer automatically sets the permissions such that "Everyone" can read from this directory.

Once the imaging task is finished, the file copies are usually removed. However, if an imaging task fails, the files are stored…

When a LANDesk managed endpoint is reporting inventory and patch level information to the core server, it leverages a web API endpoint found at https://<coreserver>/upl/async_upload.asp. This endpoint does not properly sanitize user-provided values, which allows for an attacker to both control the uploaded file extension and the uploaded file location.

As this is an ASP.NET web page, we can simply open the file in a text editor to see the vulnerable code. I opened it using Notepad++ to take a look.

The…

The Solution

Let's start things off right. For those of you who've ended up on this page searching for a solution to this issue, I won't make you read through this entire post to find it.

To resolve this issue, simply delete your passwords.conf files from the local folder within the affected apps and reconfigure those apps.

If you want to understand what makes this issue occur, and why deleting the passwords.conf file resolves the issue, please keep reading for the full breakdown.

The Cause

I ini…

Overview

I feel like the existing DFIR tooling I've used is crazy complex. That makes it pretty hard to separate signal from noise during forensic analysis and incident response, and I'd like to dive into building some tools to fix that gap.

Standard two-dimensional user interfaces provide a barrier to analysts trying to get to the information they need. Don't get me wrong, I've seen some pretty amazing analysts who can just kinda dive in and find exactly what they're looking for. Th…

What does Timmy do? Now that's a good question. Timmy is the endpoint agent described in my last blog post, DFIR Tooling - Outline. Timmy will eventually be responsible for facilitating all communication between the user's virtual reality headset and the endpoint on which the user is conducting their forensic analysis. Right now though, Timmy is just learning how to walk.

Secure Network Connectivity

I just finished implementing some basic security for Timmy's network connections using golang.o…

Previous Update: DFIR Tooling - Timmy and His File System

It's been another slow week for me over here, but that's very much a good thing. I spent some time getting ready to add network connectivity to Timmy, which requires me to wrap my head around channels and goroutines. Goroutines are a simple, built-in, lightweight concurrency mechanism, while channels are the built-in intraprocess communication mechanism in Go. I'll need to combine these two components to allow asynchronous communicatio…

Last week's post: DFIR Tooling - First Code Review

My Client struct is getting a bit more bloated than I'd like it to be, but I don't know enough about Go's concurrency model to refactor it just yet. This week's changes were small but significant, laying the groundwork for asynchronous command handling within Timmy.

The first of these changes adds a simple "command.Message" struct to replace the string value within command.Handler's "Handle" method. The new c…

Last update: DFIR Tooling - Command Handling

I'd been trying to maintain a slow but steady pace while implementing Tim, but I'll be honest. I got bored. Slow and steady wins the race and all that jazz, but there's such a thing as too slow of a pace. On Friday I considered that Tim isn't supposed to be the challenging part of this project. Rather, the VR stuff is where I want to spend all of my time and effort. To that end I decided to spend this weekend rewriting Tim in Python so that I …

Last Update: DFIR Tooling - python-tim

A friend of mine asked me to do an "Intro to Wireshark" sort of writeup, but I don't know Wireshark all that well. Instead I wrote a quick and dirty packet capture plugin and drew up some diagrams to visualize how it all works. The Divert plugin (available here) is one I've been tinkering with on and off for a while now, so it came together really quickly. It leverages WinDivert (via pydivert), a dynamically reconfigurable filter driver for Windows.…