Podcast-Ep-9 — From Darkness to Light
Podcast-Ep-9 — From Darkness to Light
In this episode of “Sources and Sinks, a conversation with ShiftLeft’s lead security researcher — Niko Schmidt. Niko opens up on his process, what he sees as the key threats and how developers can improve their game to build more secure applications
As a fun addition, he tracks his journey as a security research prior to ShiftLeft and narrates serious yet amusing incidents of corporate security assessments.
A summary re-production of the podcast is provided below
Alok — Hello Niko, What is the most difficult that you find to analyze software code?
Alok — Tell us about your process? How do you go about analyzing software code?
Niko — Depending on how much time I have, I go for the basic vulnerabilities , like XXE or SQL injection first, before I try to understand the application. But only if i related method calls are present. For more complex vulnerabilities, you need to understand the application, at least to a certain degree.
Alok — What tool do you use to examine the code and create scripts and policies?
Niko — Actually i am using our own tooling, ocular, most of the time. We have some scripts that give you a good high level overview of the application, like routes and according handler, interesting sinks.
Sometimes we see new frameworks or libraries and I have to adjust these scripts or write new ones.
Alok — You have seen thousands of code pieces in the last 2 years? What are the top issues that you see repeatedly?
Niko — Actually, it was 3 years with ShiftLeft and several years before. During this time I’ve often seen the classic vulnerabilities which I mentioned. It seems that SQL injections and XSS won’t die. The size of the company has no impact, you see it in big(ger) and smaller companies. Deserialization issues are also often happening to Java and I am not predicting that they will stop any time.
But, like many researchers or pentester, I do have some favourites. I like to check HTTP Headers. Developers seem to ignore custom headers or they do not handle them right. Meaning, they escape but don’t validate it. For example, I often find that developers are reading an IP address from a header file but they are not even checking whether the variable is a genuine one, if the data inside that field is valid or not.
Alok — What will be your recommendation to developers?
Niko — I understand that developers are paid to write code and not being security professionals and they often have other priorities but for me it makes sense to at least scan your application with open source tools. There are many good open source tools out there, that are well documented and easy to use.
There is also a lot of documentation for common vulnerability patterns. OWASP, just to name one, is pretty beginner friendly. You can still have security issues but at least you raised the bar for attackers.
Alok — Ok, Niko — Let us move to a different topic. I know you were a penetration tester and a code auditor in your past life. I am sure you have very interesting stories to tell.
Niko — . Let us see, of course I am not going to identify them. But I will tell as much as I can talk about them.
Few years back, before ShiftLeft, I was working on a contract to pen test a web application of an international clothing company. The application required me to create a login but was missing a CAPTCHA, so I was able to easily send automated requests. Luckily, the application had a check if the email address is already known and gave me an error message if this was the case. So I downloaded a list of first names from somewhere and just brute forced the email address check, starting with [email protected], then [email protected] and so on. Enumerating users is not too exciting but luckily the page also had a password reset feature. After some tests with my own account, I figured out that I was able to control a small part of the confirmation link in the password reset mail. This made it possible to redirect the customer to a domain that I control and thus to a fake page, with a fake login.
So long story short, I was able to harvest customers’ email addresses, trigger and forge content of emails from the company so that the customer lands on a page that I control.
Alok — That is a scary scenario and very concerning. On the other hand, I am sure you had many amusing moments? Tell us about them
Niko — Oh yes, this one is amusing. I was on a contract for an online educational software company based out of Europe. Now, while I was testing their web application, I quickly hit a SQL injection and I started to exfiltrate data. However, after 10 minutes or so, suddenly the SQL injection stopped working. An exploit usually never goes away in the middle of a test.
This was unusual. So, we asked the security administrator and we came to know something very bizarre. As we were testing, a network administrator (who somehow was not privy to this effort) noticed a huge spike in data going out of the company. He investigated and alerted an engineer who promptly applied a patch to step data exit. They accidentally fixed the SQL injection without them ever knowing about the existence of a SQL injection.
You never fix/touch the app while the test is going on. This was crazy — but we eventually learnt that their main admin server had a four letter password. Security was clearly not their forte.
Alok — That is amusing but disturbing at the same time.
Alok — Niko, it was a very enriching discussion with you. Thank you for joining the podcast.
Niko — Alok, Thanks for having me.
Podcast-Ep-9 — From Darkness to Light was originally published in ShiftLeft Blog on Medium, where people are continuing the conversation by highlighting and responding to this story.
*** This is a Security Bloggers Network syndicated blog from ShiftLeft Blog - Medium authored by Alok Shukla. Read the original post at: https://blog.shiftleft.io/podcast-ep-9-from-darkness-to-light-8c6e32cb522d?source=rss----86a4f941c7da---4