http-wokou, a smart web proxying framework
2024-04-04 02:09:45.890412171 +0000 UTC
An update, For a ripe Wednesday evening! I have not worked on Kyoketsu in awhile, let alone posted in a few weeks. i have been busy working on a new project called http-wokou, getting my LLC setup for Chiralworks Software, business administrative stuff, and my other endeavour in starting a media company with some of my cohorts.
In any case, http-wokou is an idea I had for an HTTP proxying framework, that is capable of proxying complex modern web apps that utilize multiple domains, and have security policies like CORS. I could see it playing a part as a late stage red team engagement tool for doing things like credential harvesting, or DNS tunneling out of a strict network.
repo is on my git at git.aetherial.dev/aeth/http-wokou
Effectively, the tool works by working with a few things defined by the user:
1. a list of trusted/expected domains
2. a map of URI 'slugs' to domains
3. page rewrite specifications
The proxy attempts to map the requested URI to a domain in its routing table, stored in memory. If it does not find a match, it attempts to call that URI on each domain in the ‘trusted domains’ specification. Once it receives a response, it will map that URI to that domain, for future reference.
Before trying the shotgun method, it will attempt to use the ‘slugs’, meaning if the the requested URI contains a substring from one of the ‘slugs’, it will automatically map that route to that domain. The more specific of a slug is specified, the more effective and accurate the route generation will be, at the expense of your time.
Before the proxy responds to the client with any data, it will perform modification to the content being sent back, i.e. whatever is specified in the page rewrite rules, so you can specify to find domain names and rewrite them to the proxy domain, or things of that nature. This is to prevent your client from leaking its traffic away from the proxy, which in a late stage red team engagement, could mean failing to emulate internal auth providers, getting flagged as suspicious because your machine made a request to a high-profile, blocked domain, or having a CORS policy prevent the web app from being proxied.
This is a relatively expensive process, because it has to iterate over the response and replace all of the matching byte arrays in the response from the server. To mitigate this, I have it configured to also static js, css, and html files in memory. This way, when a client requests a URI that the daemon has stored in its cache, it will send that resource back to the client without having to retrieve it from the downstream server and do page rewrites.
A part of the project that I’m proud of is that whenever the program receives a SIGINT system signal, (ctrl + c) it will dump the routing table to disk so that the daemon can reuse the routing table at next boot, which i think is pretty cool. It also allows for the daemon to be portable, and build up a library of routing tables for different services that you may wish to proxy. this is taken from ./keiji/pkg/routing.go
c := NewController(cfg, rmaps)
sigChanel := make(chan os.Signal)
signal.Notify(sigChanel, os.Interrupt, syscall.SIGINT)
go func(core *Controller) {
<-sigChanel
c.RouteMaps.ExportRouteMap(c.Config.RouteMapPath)
os.Exit(1)
}(c)
Its currently relatively hack-ey, but over the next few weeks I want to clean up the codebase before I lose steam and inspiration, haha.