Keyboard shortcuts

Press ← or → to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

Introduction

My Rusty Pension Fund is my attempt at writing tools for my bug bounty hobby.

I have scanners, fuzzers, wordlist generators, task managers, iOS and macOS apps, the WORKS! Although most of it doesn't really work, neither have I ever found a real bug with any of these tools.

Still, all good fun to build and learn stuff!

Its focus is to build a very fast and memory/cpu optimized scanner for various scenarios. The main initial focus are specialized scanners for:

  • TCP Syn port scanning
  • TLS certificate Subject Alt Name scraper
  • HTTP(S) scanning

The Rust library will implement it's own custom network stack using libpnet to be able to optimize everything as much as possible, similar to the masscan service. The network stack should be easily extensible, adding new scan types in the future that leverage the custom network stack.

The core concept of the network stack is that it uses libpnet in datalink layer and contruct my own ethernet, ip and tcp packets. It will be running in two separate threads, one for sending packets and another for receiving packets. Similar to masscan, synchronisation of the send and receive thread is avoided by using the tcp sequence and ack numbers with a hash to keep track of what sending packet corresponds to what received packet.

How do the libraries work together

Main principle is:

All MRPF tools like scanning, filtering, fuzzing logic should be in external libs (eg. tcp_syn_scanner, cert_transparency, matchers, http1_scanner, etc).

This will allow us to build different 'front ends' for these tools.

MRPF Jobs

  • The mrpf_core::tasks is the only place that defines Tasks.
  • Task pull in all external MRPF tool libs in and executes the them in the execute function of the relevant tasks.
  • The worker nodes are very simple. They pull in the mrpf_core::tasks library and run the tasks. With this architecture, it should be possible to have a single lambda that can execute any arbitrary task. This would make the AWS specific code very small, allowing us to move to other workers without any real effort.

TBD if we would separate the MRPF API for scheduling jobs as a separate api or integrate it with the MRPF API. A compromise could be to build a separate API, but do include endpoints for both MRPF API and MRPF Jobs into the MRPF API Client.

WebSocket interface for iOS/macOS frontend

The mrpf_scanner_api provides a WebSocket interface for real-time communication between iOS and macOS applications. It allows you to schedule tools and receive updates on their progress.

MRPF API

This is an API that stored all our recon data.

MRPF API Client

This is an async client for interacting with the MRPF API.

CLI

The mrpf_cli is a command-line interface for interacting with the MRPF framework. It allows users to initiate scans, manage tasks, and retrieve results directly from the terminal.

At the moment it hasn't really been implemented yet.

How will we build REST API's?

I want it to be reasonably easy to move away from AWS for my REST API's. I'd also want to try and save costs as API Gateway can get expensive. You could run a Rust API fully inside a single lambda. There are two well known paths for this:

Remember 'The Algorithm'

Elon musk's algorithm, should be applied to everything, in this specific order:

  1. Question every requirement

    What things do I REALLY need?

    • Continuously find attack surface
    • Quickly fuzz endpoints with payloads
    • Detect anomalies in responses

    What things don't I really need but am I often looking for?

    • Store all the results
    • Have a fancy UI

  2. Delete any part of the process you can

    The most common thing that an engineer does is optimizing a thing that shouldn't exist.

  3. simplify and optimize

  4. Accelerate cycle time

  5. Automate