8 comments

[ 2.7 ms ] story [ 33.1 ms ] thread
I wonder how many sites have left the /debug/pprof endpoint enabled in production. Sounds like something pentesters should keep in mind.
http://mmcloughlin.com/posts/your-pprof-is-showing - "Golang’s net/http/pprof package is incredibly powerful: it’s trivial to debug a running production server. In the process it’s equally easy to accidentally expose your debugging information to the world. In this post we use the zmap project to show this is a real problem in the wild, and explain preventative measures you can take."
However it's not very hard to wrap pprof's HTTP handlers with your own one, so you can add a layer of protection for it.
Pretty much any brute force pentesters will check for exposed endpoints of any kind or anything open/accessible on a network and/or a particular server/desktop/system. Security software are pretty thorough nowadays.
Slightly off-topic, but the web-based visualization tool - Chromium Catapult's Trace-viewer [0] - used to present the profiling data here is pretty nice I think.

The input JSON data format for Trace-viewer is also simple, so it's easy to to leverage it when creating a profiling tool. As a simple example I built a POSIX function call tracer for Linux - cpuusage [1] - which uses it.

[0]: https://github.com/catapult-project/catapult/blob/master/tra...

[1]: https://github.com/d99kris/cpuusage

justforfunc - www.youtube.com/watch?v=ySy3sR1LFCQ