[HN Gopher] Show HN: Pakiki Proxy - An intercepting proxy for pe...
___________________________________________________________________
Show HN: Pakiki Proxy - An intercepting proxy for penetration
testing
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!
Author : pipeline_tux
Score : 69 points
Date : 2023-10-27 15:35 UTC (7 hours ago)
(HTM) web link (pakikiproxy.com)
(TXT) w3m dump (pakikiproxy.com)
| grezql wrote:
| Does this work on applications with SSL pinning?
| pipeline_tux wrote:
| 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 Pakiki to intercept the traffic itself.
| pizzalife wrote:
| Looks interesting. What would be the main benefits of switching
| to this from BurpSiute?
| pipeline_tux wrote:
| 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.
| m3047 wrote:
| 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.
| pipeline_tux wrote:
| 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.
| Cupprum wrote:
| 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?
| pipeline_tux wrote:
| 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
| Fnoord wrote:
| 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
| RockRobotRock wrote:
| Using Frida has worked well for me in the past :)
| VoidWhisperer wrote:
| 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
| Cupprum wrote:
| 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/
| KomoD wrote:
| So like burp suite...?
| pipeline_tux wrote:
| 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.
| 617a6572 wrote:
| Nice to see another tool, but what exactly are some of those
| problems you/others are having?
| pipeline_tux wrote:
| 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.
| Sytten wrote:
| If I could get a dollar for each time people tell me Caido is
| like Burp Suite
| Fnoord wrote:
| 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 Pakiki 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 Pakiki compare to mitmproxy?
| ValtteriL wrote:
| 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?
| pipeline_tux wrote:
| 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).
| robocat wrote:
| Pakiki is a maori verb meaning to probe:
| https://maoridictionary.co.nz/search?keywords=pakiki
|
| The macron (aeiou) 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?
| pipeline_tux wrote:
| Thanks for the suggestion. I've added it to the todo list.
| Sytten wrote:
| 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!
| pipeline_tux wrote:
| 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!
| Sytten wrote:
| 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).
| ping00 wrote:
| 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!
| Goofy_Coyote wrote:
| 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).
| ping00 wrote:
| 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).
| pipeline_tux wrote:
| 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.
| drewcoo wrote:
| All proxies intercept.
|
| This one fuzzes, so it's also an injecting proxy.
___________________________________________________________________
(page generated 2023-10-27 23:00 UTC)