I did wrote a small open-source tool in Rust. And I too did encounter that kind of issue when I did start to build a .deb.
Honestly, it was the kind of bug that is not fun to fix, because it's really about dependency, and not some fun code issue.
There is no point in making our life harder with this to gatekeep proprietary software to run on our platform.
I have been generating documents for a while using https://github.com/enhuiz/eisvogel. It's nice to use markdown, but I feel really limited, and can't do much customization.
I don't use GDB a lot. But when I do, I generally use the pwndb extension.
It's written for exploit development, but even for debugging a C program. It makes things a lot nicer.
And ultimately, what is inside your pentest report ? Not a graph, a list of things to do:
- SMB signing.
- Don't use the domain admin to manage every machine.
- ...
The main reason this phrase is so popular, is that it panders to the hacker community: "We are the smart guys, all the defenders do is excel sheets."
IMHO, the nugget of truth in this is that defenders can spend considerable amounts of time on things that don't matter. Like doing CIS benchmark by hand on all servers. While missing the low-hanging fruits that would give them a strong security posture.
In a lot of companies, the defenders are just sysadmins that don't have any idea of what they should focus on.
SEEKING WORK: Pentest / AppSec / Training / Cybersecurity | Remote, France
Cybersecurity expert, with 8 years of experience, I have audited multiple complex systems. From Internet Gateway (Linux embedded), to innovative web apps and complex Active Directory environment of Healthcare providers.
So in that regard, Alpine is less secure by using musl. However, having a small and understandable system is a real advantage when it comes to security.
All Linux binaries are compiled with PIE nowadays. You can run `checksec` on any binaries on Ubuntu, and it will have those properties.
(You can install checksec with `pip install pwntools`).
On the other hand, GLIBC has, to my knowledge, the most hardened heap implementation out there. And there are more mitigations for double-free and other heap exploits on GLIBC.
So in that regard, Alpine is less secure by using musl. Having a small, understandable system is a real advantage when it comes to security.
SEEKING WORK | France, Remote | Pentester, Cybersecurity expert
I am a cybersecurity consultant / pentester / trainer with 7+ years of experience. I have audited successfully internal networks, web applications, and embedded environments.
I also do trainings for professionals and students.
Getting out of bed and "real stuff" is supposed to be part of a pentest.
The problem is more the sheer amout of stuff your are supposed to know to be a pentester. Most pentesters come into the field by knowing a bit of XSS, a few thing about PHP, and SQL injections.
Then you start to work, and the clients need you to tests things like:
- compromise a full Windows Network, and take control of the Active Directory Server. Because of a misconfiguration of Active Directory Certificate Services. While dealing with Windows Defender
- test a web application that use websockets, React, nodejs, and GraphQL
- test a WindDev application, with a Java Backend on a AIX server
- check the security of an architecture with multiple services that use a Single Sign on, and Kubernetes
- exploit multiple memory corruption issues ranging form buffer overflow to heap and kernel exploitation
- evaluate the security of an IoT device, with a firmware OTA update and secure boot.
- be familiar with cloud tokens, and compliance with European data protection law.
- Mobile Security, with iOS and Android
- Network : radius, ARP cache poisoning, write a Scapy Layer for a custom protocol, etc
- Cryptography, you might need it
Most of this is actual stuff I had to work on at some point.
Nobody knows everything. Being a pentester is a journey.
So in the end, most pentesters fall short on a lot this. Even with an OSCP certification, you don't know most of what you should know.
I heard that in some company, people don't even try and just give you the results of a Nessus scan.
But even if you are competent, sooner or later, you will run into something that you don't understand. And you have max 2 week to get familiar with it and test it. You can't test something that you don't understand.
The scanner always gives you a few things that are wrong (looking at you TLS ciphers).
Even if you suck, or if the system is really secure. You can put a few things into your report.
As a junior pentester, my biggest fear was always to hand an empty report. What were people going to think of you, if you work 1 week and don't find anything?
Is this exploitable ?
With current mitigations (NX, Stack Canary, ASLR), I don't see how a buffer overflow on it's own could result in Remote Code Execution.
Honestly, it was the kind of bug that is not fun to fix, because it's really about dependency, and not some fun code issue. There is no point in making our life harder with this to gatekeep proprietary software to run on our platform.