Show HN: Pākiki Proxy – An intercepting proxy for penetration testing | Hacker News Reader

Show HN: Pākiki Proxy – An intercepting proxy for penetration testing

pakikiproxy.com

97 pointspipeline_tux43 comments

Hey HN, I've been working on an intercepting proxy for penetration testing over the last few years in my spare time.

Some points of difference from the existing tools:

* The UIs are built using the native platform frameworks, meaning they look and behave like other applications on the desktop.

* It has a fully embedded and integrated Python scripting engine.

* It’s fully native meaning it’s nicer on system resources.

* It has a number of built in scripts to automate reconnaissance, content discovery, authorisation checks, etc.

* The core of it is open source.

I'm really keen to get any feedback!

Open articleView on HN

Pākiki is a māori verb meaning to probe: https://maoridictionary.co.nz/search?keywords=pakiki

The macron (āēīōū) lengthens the vowel sound (Latin has this too) otherwise pronounce the vowels the same as Spanish. Lengthened vowels are harder for most American speakers to get right: https://youtu.be/tPi2jtU7Tl4?t=6m23 Vowel length matters in New Zealand (e.g. pronunciation of can't causes problems).

Perhaps could be added to the docs?

Thanks for the suggestion. I've added it to the todo list.

Love it, specially the python scripting engine.

Also, don't listen to those who say things like "soo, like Burp?" (the ones who do it to belittle the effort).

People used to say (and still do) Postman is "just a wrapper around curl", and I was like, "So is Operating systems, they're a wrapper around hardware, and C is a wrapper around assembly, and Python is a wrapper around "I don't want to manage memory, let's make a web app instead", What's your point?" lol Postman is now worth couple of billions btw.

You're doing a great job - keep at it. Ping me if you needed testers (I work in AppSec/Red teaming).

this actually feels like a lightweight feature-rich wrapper, unlike Burp (which I really love btw, not hating on it) which can cause my computer to slow down noticeably with extensions loaded. This is an unfair comparison though, because I derive a lot of value from Burp's BApps and choose to have quite a few of them loaded. The performance hit is worth it to me in this case, but I think it's fantastic to see more lightweight, WYSIWYG (dare I say frugal) alternatives to what's grown into a bulkier tool (Burp). Kind of like XFCE vs GNOME.

Hi there! Co-founder of Caido (https://caido.io) here.

Glad to see more competition in the space, we also went the route of using an API (built in Rust). We decided to focus only on a web UI in vue.js I will look how you are storing data and all, we went the sqlite way to save on RAM.

Looks like we are both going after Burp, it's not going to be an easy ride for sure. What we found is it is very hard to make people in enterprise switch and the 100$/y pricing really isn't enough to build a serious business without enterprise clients at a higher price point.

Anyway, best of luck!

Hi!

Yeah, it seems like we've identified similar problems and addressed them in reasonably similar ways. Likewise, I've went with SQLite as the project file format, with the files being compressed when saving so that users can transfer/share the project files easier.

Thanks for the insight on the pricing. I've been working under the assumption that if a few people on my team at work wanted to spend $100US each on tools, that they think would improve their productivity, it'd be a no-brainer and easy to justify.

I definitely think that more competition in this space is good for the industry as a whole, and likewise wish you the best of luck!

We don't currently compress data but we might at some point. We found that the most significant speed increase is by splitting the data into multiple files. Otherwise it becomes very slow at 10-20GB range.

Yes and your 400$ plan is a good idea. But we did the math at 100$ (Port Swigger financial records are public) and it is not easy to make them work as a full time gig. And it's not really possible to get funded just for that market, it would need to 10x to be VC viable.

If you ever want to talk further, do shot me an email (emile [@] caido.io).

Interesting, wasn't aware that there were Burp alternatives being worked on. I'm going to play with both of these to see how they compare. Thanks to both you and OP for sharing!

Hi, I took some time to use Caido. I really like it, especially the ability to switch between projects. I also thought the UX that introduces users to the application was well-done. Tbf, I have years of experience with Burp, but I think anyone would have been able to follow along. Nice, clean UI and installation was breezy. Great job! Looking forward to seeing how this project develops, and I wish you success in your competition with the incumbent.

This may be a really broad question, but would you mind touching on why you developed this in Rust? Is that the reason why this application feels snappier than Burp (JVM), or is it just less taxing on system resources? Please feel free to tl;dr it if that's easier :)

Also, the coolest looking feature is the AI assistant undoubtedly -- is there any chance that customers can BYOT in the future and supply a personal OpenAI API token for example?

Thanks for the review and kind words. This was really one of the core goal to make it super accessible.

We developed it in Rust because we wanted to create a client/server architecture that you can deploy everywhere (Caido runs even on a rapsberry pi). We worked a lot on the frontend to make it snappy too, so its a combination of both.

Yes for sure, there is a privacy concern too with us forwarding request. It is in the issues of https://github.com/caido/caido.

Hi, just wanted to say that I walked through this and it's really neat. I'm running it all through WSL on a reasonably powerful laptop (ASUS G14) and performance has been buttery so far. I especially want to commend you on the clear, simple-to-use UX and UI. This will definitely fill a niche for me at work if I have to use an underpowered jumpbox to test internal web applications.

One UX point: I may have missed this, but when I start an injection attack, it would be nice to see a real-time table of the output so that I can see which injections have been tried (kind of like how you can see it in Burp Suite with Logger++ or the sub-window that opens up when you start an Intruder attack). Totally respect a conscious choice to not go down this (potentially) resource-intensive 'view', but curious if that's on the roadmap. Right now I just get a spinning animation after I hit Run, and I don't see any output in the sidebar where it says "Scans will be shown here once they have started".

In all honesty, I probably will stick with Burp Suite for my bread-and-butter web app testing flow (also helps that my org pays for a Pro license), but I want to thank you for the effort put into this and the courage to explore a new modality (web app testing without a resource-heavy proxy tool like Burp).

Thanks for the kind words and feedback!

There should be a real-time table when you're running a scan so that sounds like a bug. Having a real-time table is surprisingly light on resources. I haven't done a huge amount of testing on WSL, so I'll take a look and fix it in the next release.

Looks interesting. What would be the main benefits of switching to this from BurpSiute?

Thanks! There's a few points of difference in terms of approach/philosophy.

Firstly, I really wanted to focus on usability. So there's a native UI on each platform, using GTK on Linux, and SwiftUI on MacOS. This means that we can integrate fully with the desktop, and adhere more easily to the human interface guidelines on each platform. I'm also not necessarily trying to go for 1-1 feature parity with Burp, so that I can keep the UI simpler (especially where good standalone tools exist).

I'm trying to target it to be more resource-friendly. Some of my pentesting colleagues at work struggle to run all of their tools in less than 32GB of RAM, and most need 16GB of RAM, and Burp is a not insignificant contributor to that. By comparison, I've been primarily testing this in a Kali VM with 2GB of RAM allocated, and while it doesn't always run smoothly, it often runs pretty well.

Lastly, there's embedded automation with Python scripts. There's a number which are built in, but it's also easy to expand on those and create your own. You can use those for reconnaissance, custom discovery of vulnerabilities or exploitation. I've got plans to expand that engine and capability even further.

I’m exactly the target market for this.

I won’t pay for subscriptionware. I switched from Premiere to Resolve just to avoid having to be someone’s MRR and I now pirate Lightroom pending its replacement.

It’s a terrible, user-hostile model.

I don’t think developers should be entitled to payment in perpetuity for work they did once.

But do you think “work they did once” holds true for the majority of software that uses subscription based pricing? No updates, no migrations to new OSs, no bugfixing, no support, would you want that? Should people just write perfect software off the bat?

Most of the time, I don’t want the new version or features. If I didn’t think the current version were suitable for my needs, I wouldn’t buy it as-is.

You seem to be conflating future updates with the software as it stands today.

I am not buying support, I am not buying upgrades. I’m buying software once today (and even that is an exception, as the majority of my tools, including 100% of the most critical ones, are free software).

Additionally, I find proprietary software vendors who do open source cosplay (“open core” is something made by people who dgaf about software freedoms) to be generally disdainful. Open core is a slap in the face; nobody is forcing proprietary software vendors to be in denial about being proprietary software vendors.

I like the model in use by software such as Hopper (disassember with nice native UI) and Sublime Text. You buy a license for a major version and get updates for that for X years. You may use these versions forever. But a new major is gonna cost you.

I'd never buy subscriptionware for hobbyist or fun purposes. Or so I thought. Because I do pay for a WoW sub :/

Requiring Sonoma seems... weird? It's still pretty much unstable for serious work. Especially if you build with GTK, not with native frameworks. Both Burp and Caido are much more lax, working on HS/EC.

Cool project!

I have one question though, how do you intercept TLS. Let’s say i would connect my phone to your proxy, and try to search something on the web. Wouldn't the connection not be trusted?

Thanks! The tool has a built in certificate authority (CA) to generate TLS certificates. So to intercept TLS traffic from a phone, you export the CA's root certificate and import it onto your phone. If you're on PC, you can also launch a browser preconfigured to intercept traffic.

This is the standard pattern for these kinds of tools.

As it's not always a straightforward process for people who haven't done it before, there's instructions for a variety of platforms in the documentation: https://docs.pakikiproxy.com/#/getting_started/intercepting

Won't work with certificate pinning. Although if you have root, you can even work around that. See this recently on HN mentioned article by Kaspersky [1], using mitmproxy.

[1] https://news.ycombinator.com/item?id=38034269

Using Frida has worked well for me in the past :)

I'm not entirely sure if it is the case here, but many tools that intercept TLS have you trust a certificate in the OS or browser level that they then use as a MITM on the proxy to be able to decrypt the requests

I previously used Proxyman [1] on iOS to the http requests send over TLS. It worked rather nicely. Proxyman in this case starts a VPN which handles all the traffic. It uses custom certificate to decrypt the messages.

[1] https://proxyman.io/

Looks good!

Cross platform native GUI and you are doing this all alone? Feels very ambitious.

Are you planning to go full time on this?

What kind of stack are you using?

Thanks! Yeah, it was definitely an ambitious choice, but I think it results in a better product, and I'm really happy with how it's turning out. For now it's just me part time, but I'm hoping to go full time or near full time next year.

In terms of stack, there's an open source core written in Go which exposes an HTTP API. The UIs then use that API. There's a cut down web frontend written in VueJS (useful for forward deployments), a GTK frontend for Linux written in Vala, and the MacOS version is using Swift/SwiftUI (with some use of AppKit where that's not applicable).

Then (because this isn't ambitious enough) once those are polished, I plan on doing a native Windows frontend too (likely using C# with WinUI 3, but to be confirmed).

Nice with native desktop UIs! It's like a lost art these days.

Did a desktop app some years back using wxWidgets. Slightly less ambitious than doing separate native UIs for each platform like you're doing here, but still gave me a native enough feel that I was happy with the compromise.

Does it work if you have a work vpn like Cisco Anyconnect or Cato. Proxyman does not with those Vpns :(

I haven't tested with either of those unfortunately, but I do regularly test when connected to a VPN using OpenVPN.

From a PC/Mac, if you can reconfigure your browser to proxy traffic via Pākiki, it should work with them (and then subsequently route traffic over the VPN).

Unfortunately I'm not sure what the network routing/proxying behaviour is on mobile when you have a VPN like those configured, but my assumption is that it probably wouldn't work.

All proxies intercept.

This one fuzzes, so it's also an injecting proxy.

Awesome - love the te reo name!

So like burp suite...?

Correct. Burp is the main competitor, but it's been around a long time and I wanted to develop something from scratch to address a number of the problems myself and other pentesters have had with it.

Nice to see another tool, but what exactly are some of those problems you/others are having?

Usability and performance (for example when deployed on lower-end customer machines) are two major ones. Admittedly they have been getting better over time.

It's also not uncommon to have sites behave a bit differently when running via Burp, so given it's not open source, it can be hard to diagnose/debug what's going on.

If I could get a dollar for each time people tell me Caido is like Burp Suite

Because Burp Suite is the defacto tool for web pentesting. So that is what people know.

I've never liked Burp. Java, requires GUI, and subscription costing 365 USD/year. Where without a license you cannot even do trivial automated stuff (forcing you to click 'OK' all the time; easily circumvented with e.g. AHK).

At the very least a personal license for Pākiki is only 100 USD/year. Which is a lot less barrier of entry for amateurs (if you're a for-profit web pentester /care). How does Caido and Pākiki compare to mitmproxy?

We are also at 100USD/y. We both use a client / server architecture. We are both closer to burp suite in terms of functionality (aka focus on finding vulnerabilities, replay (invalid) traffic, mapping sites, etc compared to mitmproxy that is more a developper tool.

Briefly reviewed your product. Seems like OWASP ZAP is your competition: https://www.zaproxy.org/

It runs entirely in the browser so it uses the browser "native" frameworks.

Correct, ZAP is one of the main competitors, and the core functionality is the same. While there's a browser Head-up Display, the primary UI is still a Java desktop-based application.

Does this work on applications with SSL pinning?

No, it doesn't unfortunately. In a professional testing world, we'd normally just ask clients nicely to disable that for our testing. If you're testing something where you don't have a relationship with the developers, then Frida is my go-to tool to get around that. Although once you've disabled SSL pinning, you can use Pākiki to intercept the traffic itself.

Reply on news.ycombinator.com