Infector API

Infector API

The infector API (not at all a malicious thing, although it defintely started as a malware delivery system) is a long term project I started on in March. The primary goals were to establish a functional API server written entirely in Rust. Currently, the API server offers several different services, hooks into various technologies including a SQLite database for authentication, and has SSL/TLS support via Let’s Encrypt. In it’s current incarnation, it isn’t entirely ready for deployment. However, I thought this would be a good time to start documenting the journey I’ve taken creating this, and more importantly, what I’ve learned creating it.

Overview

The Infector API (named after one of many one-off domains) is entirely written in Rust. The project uses a SQLite3 database for storing account details and API keys and Axum for handling incoming requests and serving responses. A full list of the components can be found in the toml file in the repository. A major feature of InfectorAPI is the PowerShell wrapper that is designed to provide easy access to the API for Windows environments. The PowerShell wrapper is a module designed around the principles of ease-of-use, modularity, and scalability. It currently supports all API endpoints in development.

The current state of InfectorAPI is more proof of concept than realized service. The API has several functional endpoints that can be utilized, including:

• Authentication
• Operational
• Conversion
• Scanner
• Endpoint
• Testing

These endpoints each provide basic services and give documented examples for expanding service offerings and utilizing the modular design of the InfectorAPI.

InfectorAPI has specifically been designed for scalability and modularity. To achieve these goals, every endpoint exists as a Rust module that is imported into the main server application. Further, API responses and requests are standardized and shared across the server application and API endpoints. Similarly, there is a custom logging system that has been created for tracking server access, authentication, and endpoint utilization.

Following, is some high level information regarding authentication and API scheme. More information can be found on my GitHub. The README in particular contains more in-depth information on various endpoints and resources.

API Scheme

• Main Server Application
  • Imports:
    • Custom logger
    • Custom structs
    • Endpoint modules
  • Returns:
    • Serves the API
• Endpoints
  • Imports:
    • Custom structs
  • Returns:
    • Formatted endpoint response
• Logger
  • Receives formatted log data and writes to log files

Database transactions are handled in both the main application and endpoints. The connection is passed through the function calls made by the main application (where the pool is created) to the endpoint modules (where connections occur). Each endpoint validates the connection before returning data.

Authentication Scheme:

Authentication is handled through a multi-step process. A user must first sign in to the API via a username and password. Once validated, the server returns an API key that is valid for 30 minutes. The user then uses the API key in subsequent calls to access endpoints. A username/password authentication alone cannot access any resource other than the authentication endpoint. If at any point the authentication process fails, the user will receive an unauthorized error.

Module System

Authentication

The authentication endpoint is only utilized for requesting an API key. This endpoint correlates to the Connect-InfectorAPI cmdlet in the PowerShell module.

A valid request to this endpoint requires a JSON body with username and password parameters.

{
  "username": "username",
  "password": "password"
}

A successful authentication request will return an API key that is valid for 30 minutes. The API validation time can be checked with the Get-InfectorAPI expire_time command.

Operational

The operational endpoint is used for making requests that deal with the operationality of the server or the current session. This endpoint contains methods for retrieving the API documentation and checking API key expire times. Further development of this endpoint may include the ability to download logs and other administrative actions.

This endpoint relates to Get-InfectorAPI in the PowerShell wrapper.

A valid request to this endpoint requires an API key.

{
  "api_key": "key"
}

Conversion

This endpoint is used for converting or decrypting data. This endpoint specifically demonstrates the flexibility in API requests. Certain requests require encryption_key or nonce parameters in the body JSON. These requests are handled by the same shared request struct through the use of optional struct parameters.

This endpoint relates to Convert-InfectorAPI in the PowerShell wrapper.

A valid request to this endpoint requires an API key, a content parameter, and optionally, encryption key and nonce parameters.

{
  "api_key": "key",
  "content": "content",
  "key": "encryption key",
  "nonce": "nonce"
}

Scanner

This endpoint interfaces with third-party APIs. Specifically, there are examples for VirusTotal and Shodan. It also supports running an Nmap search for a submitted address. One of the primary uses of InfectorAPI was to provide a space for APIs requiring credentials or keys to live, allowing for access to all APIs with one unified logon.

This endpoint relates to Send-InfectorAPI in the PowerShell wrapper.

A valid request to this endpoint requires an API key and a content parameter.

{
  "api_key": "key",
  "content": "address/domain/hash"
}

Endpoint

This endpoint is used for interacting with the client. Primarily, it serves to deploy scripts for pipeline execution. For example, running a powershell script with Invoke-InfectorAPI script hello_world | iex. Scripts are stored in a HashMap containing a resource locator (GitHub url, for example) and a short name for access. Calling a short name will return the script.

This endpoint relates to Invoke-InfectorAPI in the PowerShell wrapper.

A valid request to this endpoint requires an API key and a content parameter.

{
  "api_key": "key",
  "content": "content"
}

Testing

The testing endpoint is solely used for validating connections and sessions. A valid session will return Hello, World! on request.

This endpoint relates to Test-InfectorAPI in the PowerShell wrapper.

A valid request to this endpoint requires an API key.

{
  "api_key": "key"
}

Debug

While not existing in any particular endpoint, there are several debug features that are included in the API. Most prominently, sending a GET request to /hdrs will return a dump of the headers you have submitted to the server. This is available without any authentication.

Notes

Working on this API has been incredibly rewarding. I am not a developer by any means, and most of my projects have been one off scripts or tools designed for a specific purpose. This may be the largest project I’ve worked on, and it is certainly the most complete. Learning the complexities of Rust by developing a web server has been great. I’ve left numerous comments throughout the code describing what certain things do, posting helpful links for functions and content, and many times expressing how amazed I am that certain solutions actually work.