pentesting. Pentesting. PENTESTING.
New year’s resolutions
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.
🔒 Related Stories: AppSec | Secure Code | Data Breaches | Pentesting
💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Happy new year! 2024 is upon us.
I was literally up all night finishing a penetration test and I’m exhausted but I love it. And that’s all I’m going to do in 2024, besides shorter speaking engagements and IANS calls and research. No more training or sidetracking projects. Here’s why.
Why you need a pentest
If you are on a team developing software and no one actually knows how to manually exploit cross site scripting (DOM, reflected and stored), SQL injection, CSRF attacks, or file manipulation attacks then you might want to hire me to perform a pentest. I am often surprised at the number of things I find the first time I do a pentest but there are so many companies who have never had one. They don’t even realize how vulnerable their systems are. It is kind of scary actually.
I want to help more people fix up their applications and web sites. And the best way to figure out if you have flaws on your website is not a scanner — it’s to get a penetration test. Let me explain why with real world examples.
When I ask if anyone on your team knows XSS, for example — I mean knows in detail how these vulnerabilities work and how to test for them and prevent them. Because I find the most basic flaws, not something complicated. I find the complicated ones too. 😁
Application Security Scanners — SAST, DAST, and all the other ASTs
“But we’re running a scanner!” you say. So were they. They had a very well-known scanning company scan their site. So did a client before that. I could see the evidence as I was performing my test. I’m talking well-known, big name scanners. And they are good tools. But they can’t find everything.
I had trouble getting Burp working correctly on this test, because this web site was doing something weird to log me out repeatedly. So was one of the others I tested. But I got around it. I wrote about that here:
Scanners help but they need fine tuning. I absolutely love Burp. But scanners miss things. Want to see how good your scanner is? Hire me for a pentest and see if I can find anything. 😁 Then you’ll know for sure.
Scanners are tools — and like a hammer or a wrench — they are often used to their full potential by someone who knows how to use them effectively and for the intended purpose. — Me
I wrote a paper on software security scanners for one of my grad school projects for SANS Institute. Only none of the companies besides the ones offering free tools would let me get a copy of their software for my research. Why? Why do you think? I might be able to show that when run side by side, one scanner is better than another. I might also be able to show the lack of coverage achieved with an out of the box deployment of a scanner.
Code coverage
I’ve written about code coverage before. It’s something you have to address when fuzzing software and something I might write about more in the future.
Even after tweaking Burp on this last test, it did not find so many things. I could tell it wasn’t getting code coverage. I could probably tweak things to get a more automated result but I had to finally resort to manual testing due to lack of time.
I ❤️ helping developers
By the way, I don’t blame the client or the developers at all when I find these things. I was a developer. I want to help developers! I want to show them the bugs I found but also explain easy(ish) things they can do to prevent these problems across the board.
When I got hacked initially, I read the infamous Web Hacker’s Handbook among other things. I tried to read a book about BeEF but it was mind boggling initially. I knew “what” cross-site scripting was. I had a bit of understanding about the concept. But that was not my day to day focus. I was building things. I had work to do!
I never had time to stop and dig into all the intricacies of the attacks. I monitored my logs and did funky things on my web site like building a WAF before that term existed and creating a weird authentication process that blocked all kinds of attacks. I intimately knew my web traffic and what was going on and how to prevent malicious behavior — to a point. But I really didn’t understand what they were doing exactly at first.
Only now as I focus on pentesting daily to I really get to dive deep into how these things work and how to exploit them. And the vulnerabilities I listed are only a small subset of the things I test for on penetration tests. I have a client that I test year after year and every year it gets harder so I have to dig deeper to try to find something more than the simple things I found on the first test. I absolutely love that!
Repeat engagements — understanding the architecture
Repeat engagements are great because it takes some time to understand the architecture and technologies involved in a system. The next time around you can spend less time on set up and dive right in based on the prior year’s notes.
Penetration tests *may* provide more value than training
Sometimes I get asked to do training. I spend so much time putting the training together and giving it and for me, a mostly introvert, it’s exhausting. I like giving presentations but the full grind of a long class is just tiring. I also don’t think it provides as much value as a penetration test — even though I generally make more money.
When I perform a penetration test, I not only try to hack the system, but I try to provide walk throughs of what I did with screen shots to show the developers how the attacks work and how they can prevent them with holistic, global solutions. When a developer sees how their own code was hacked, I think that’s easier to understand then some generic example — and some of the things you learn in the big security training classes are so outdated or basic they aren’t that helpful.
Instead of playing whack-a-mole with a security scanner that only gets you partial findings, implement an architecture that helps prevent security problems at the core. Instead of paying a bazillion dollars for training when the people involved have their mind on other things, leverage a penetration test to learn the nuts and bolts of how attacks work — if your penetration test company takes the time to explain that in their report.
Calls are more efficient
You’d think I’d be pushing you to get time consuming training that pays me anywhere from $25–60K per team — but I’m not. Yes, that’s how much I’ve often been paid in the past.
Honestly, if people have questions, rather than hire me for a six week class, give me a call at IANS if you have a question. If I can answer it, I will, or I’ll try to recommend someone else. If it’s something on my blog then generally it’s a question I can answer. I can answer the core questions people have in a few hours instead of a week long class that no one has time for in the first place. A class is scattered about covering many topics you may or may not care about whereas on a call you can ask me the specific things you want to learn or know about.
But don’t schedule a call with me about products. Ask me about architecture. I don’t tell you what product to buy — for all the reasons above. Products are helpful but I haven’t tried them all. And so many vendors want me to “take a look at” their product for free. Why not pay me to pentest it instead or to use it on a penetration test engagement and I’ll give you some feedback. My time is valuable and I don’t want to market products for free. I talk about products I like that have value from companies I trust and respect. I don’t have time to test every product on the market and a demo is not the same as using the product.
Training Labs
About those labs. I remember trying to get through the labs in security classes, but only when I actually went back and used the tools on a daily basis and worked with them on actual projects did the information really sink in. Also some of the labs showed me how to use tools on really outdated attacks. I didn’t realize that until later. When I was teaching a particular class too many of the labs were broken (not mine) and it was nearly impossible to keep the labs in sync because the cloud providers are constantly making changes if you’re using a GUI to try to explain how to secure a cloud environment. You should be writing code anyway.
It takes so much time to build labs — and test them thoroughly — for a class. To me it feels like the time and money to build a lab is not worth the return on investment for me or the people taking the class. In most classes, I got more out of the presented material than the labs. I got more out of going home and working with the tools in real life than I did with some constructed scenario in a box.
That said, there is one set of labs I find useful that I’ve tried — the PortSwigger labs. Those show you how to use a specific tool on a specific scenario. But even then sometimes I find better videos or written material that are faster for me to consume. I’ve also found those labs to be broken on rare occasion. Labs are hard. If you’re going to build labs — good labs — it is a full time, time-consuming endeavor. I want to spend my time building things that actually solve problems instead.
I learned to program from books. That’s why I write my blog. If anyone is trying to learn how to program, the sample code is what helped me most — and that’s what I provide for anyone out there who is like me. I can write the blogs much faster than building a lab. You can walk through the steps in the same way as you would in a lab.
Will AI take my job away?
I remember the first time a computer beat Gary Kasperov in Chess. Maybe someday computers will beat humans completely but not at this point. The tools are very helpful. They speed things up. But they don’t always work in the cat and mouse game of security I’ve written about before. More on the use of AI and computers that can perform human thought processes here:
On this pentest I gave Q another shot. It was mildly helpful. I wanted to quickly add a query for how to find a certain thing in a client account using the AWS CLI. One of my questions got a quick answer and I was like cool. Maybe Q is good for that. The next basic question — how to query findings in AWS GuardDuty — not so much. First I got a query option that only got me findings if I knew the finding IDs. I didn’t. The answer failed to tell me that I also needed the detector ID. I had to resort to Google to find my answer. That kind of helped. Ultimately I scanned the AWS CLI documentation for the command options to figure it out.
Google got me closer than “generative AI.” The thing about Google is that it’s not trying to generate answers. It’s not using Generative AI (at this point I don’t think.) It’s using AI and ML but in a different way to distill mountains of information into finding the needle in the haystack page that has the answer to your question, not some generic documentation page. Google generally leads you to a page — written by a human — that explains the concept.
And by the way, that has to be improved by blocking out all the SEO spammers (see my above post on AI where I cover my experience working as an SEO expert for clients with e-commerce websites) so then the computer is not doing all the thinking. There are still humans involved.
Also, posting this for the technical not political reasons. AI can’t always be trusted. It recently came to light that a lawyer provided briefs for a court filing that included search results from ChatGPT. The results included fake cases. Just like your scanner can produce false positives. You need someone who can tell the difference.
So anyway, automation is really helpful but it still needs human tweaking, testing, and verification.
What was the point?
Oh yes — I want to build more security automation
And to get back to the point of this post — PENTESTING! Yay! I like building things. I’m still a developer at heart. And I love pentesting. And I like researching things to figure out how they work, how to fix things, and how to solve problem. I also like writing. Occasionally I like to share my work or discoveries in a presentation that helps people solve problems.
So that’s what I’m going to focus on in 2024. Sorry, no more training. I can refer you to others who do that and no — not some random person off the Internet with bot-generating content. I work with a bunch of people that I know are very well-informed to whom I can refer you. Reach out on LinkedIn for that.
The other reason I want to focus on penetration testing is because I’m building things I can never get done if I’m distracted with unrelated things that consume all my brain power for weeks or months at a time. You may have noticed I’ve been writing this blog series for over a year now:
It actually started out as, hey I’m going to show how I run one of my scanners in the cloud to capture metrics on penetration tests. But one thing led to another and I didn’t want to publish the shaky half-baked code I was using on pentests with a bunch of manual steps and security problems. I lock down my network pretty tightly in most cases and I know many don’t — so those insecure components would probably lead to problems and I would be blamed — so I had to start from the ground up.
Encryption. IAM. Networking.
Those are the big three in security when it comes to architecture.
Iteration
When I’m working on a penetration test I usually don’t have time to automate absolutely everything. But every time I perform a test I automate more and more things. It takes me a bit of time during the test but then on the next test I can do things so much faster. I also learn step by step how to improve things over time.
I started out with wanting to run a free open-source scanner than has since turned into something less desireable for my needs. I ended up explaining how to create a secure pipeline, policies and add governance to your AWS account. I’m also working through automated deployment of websites.
Because I want to use it all on pentests! I figured if I am working on it I might as well write about it and share some code to help people secure their own environments at the same time.
I just saw some person say he is mistakenly ditching DevOps on Twitter, er, I mean X, because it takes too long. He wants to go back to button pushing. I get it, but then you’re probably doing it wrong.
If you’re repeatedly re-writing code for core components you’re wasting time. I wrote about Microtemplates here:
I’m also building out some core infrastructure for deployments but it’s far from super secure just yet. Working on it.
The thing is — you might not have time or be allowed to automate everything perfectly, completely, at once. That’s why you iterate. Find the thing that is easiest to implement that is taking you the most time on each project or engagement. Automate that. On the next project or engagement — automate the next thing.
Abstraction
The best approach, if you can do it, is to figure out how to abstract out core components and build those once in your architecture. This can also help your security. A solid architecture using that concept from the start will save you years in DevOps time. That’s the principle of abstraction.
The only caveat — is that your abstracted components cannot become a bottleneck. That consideration also has to be considered when you design architectures and teams. These are things I’ve been thinking and writing about all year.
Rust
I’ve been wanting to try Rust. I had plans to do it. But I was inspired by Werner Vogels re:Invent keynote — as always. I need to get started on that so hopefully in 2024. I was starting down a path towards using golang but I’m going to try out Rust and compare.
There are a lot of programming zealots out there who will tell you which programming language to use and why all the others are bad or at least not as good. I’m not like that. I like them all! But some are better than others for certain objectives.
So those are my thoughts for the day — my New Year’s Resolutions.
We’ll see how it works out.
Off to watch my Huskies and eat tacos! Sorry no spellchecking for now.
Follow for updates.
Teri Radichel | © 2nd Sight Lab 2024
About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight LabNeed Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for PresentationFollow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab
