Salt Security recently released new API vulnerability research that details a Server-Side Request Forgery (SSRF) flaw discovered on a US-based FinTech company’s digital platform. Salt Security takes a deep dive in this video into what SSRF is, what the risks are and how their solution is preventing it.

“This bug SSRF, as well as any other bug, always starts with a human error. So there is someone who is coding your software and he made an error somewhere. And quite usually, he’s not aware that he made that error because it’s a very slight error, but in the wrong hands. So it could become very dangerous and critical,” says Yaniv Balmas, VP of Research at Salt Security, on this episode of TFiR Insights.

Key highlights from this video interview are:

• Balmas explains what SSRF is and why it can lead to dangerous situations.
• Most organizations do not know these vulnerabilities are there. Balmas gives two of the key recommendations of protection organizations can take to mitigate these risks.
• Balmas explains why education on common vulnerabilities types and how to identify and prevent them is so critical for software engineers.
• Balmas details the steps organizations can take to remediate any gaps in protection from vulnerabilities such as SSRF flaws.
• There are a number of challenges and risks financial institutions are facing when moving to the cloud and managing APIs in these challenging cloud environments. Balmas discusses how these changing landscapes are affecting FinTech.
• Salt Security’s SaaS solution aims to study API traffic in a smart way. Balmas explains how their solution integrates into any environment or service easily and how it uses behavioural features to identify anomalies and alert users.

Connect with Yaniv Balmas (LinkedIn)

The summary of the show is written by Emily Nicholls.

[expander_maker]

Here is the automated and unedited transcript of the recording. Please note that the transcript has not been edited or reviewed. 

Swapnil Bhartiya: Hi, this is your host, Swapnil Bhartiya and welcome to TFiR Insights. Today we have with us Yaniv Balmas, VP of Research at Salt Security. And today we are going to discuss the newly released API vulnerable to research from Salt labs. That kind of details, a server side request forgery or SSRF law, which was discovered on a US-based FinTech company’s digital platform. Before we talk about that, first of all, Yaniv, welcome to the show.

Yaniv Balmas: Hi, nice to meet you.

Swapnil Bhartiya: Yeah, let’s get into the midst of it. First of all, tell us what is server side request forgery and what kind of threat it is?

Yaniv Balmas: So service side request forgery, as you said, also known as SSRF, it’s basically an age old vulnerability. It’s nothing new and it was there even before we even heard the terms API. It’s been in the web forever, but basically what it does is when a user somehow inputs a URL, some kind of URL into the system, then the backend blindly trusts this URL, and it’ll go and try to browse to it or do something else with it. That creates an SSRF condition and that could lead to very dangerous situations, which is basically what we found. Obviously, as I said, it’s not a new vulnerability, but it still exists and it’s very much here and alive. And even on API layers, it’s all over the place.

Swapnil Bhartiya: So what happens with most of these flaws and vulnerability is that in most cases, companies don’t even get to know whether they were exposed to them or not. So can you give some advice what organizations can do to identify if they are exposed?

Yaniv Balmas: That’s a pretty good question. I guess that’s usually the problem with vulnerabilities. If you knew it was there, you’d probably do something about it. The problem is that most organizations don’t know it’s there and recommendations here could be… there could be a lot of recommendations, but let me just point out maybe two of the major ones.

One is to have a consistent code review and make sure that you look through your code. If you’re looking for SSRF then always look for places where you get user controlled input that’s being transferred into some kind of outgoing request or even internal request. That’s internally what you can do. But I think that’s not the only solution. I think there should be always another solution as a backup plan or two protections walking in balance and that usually would be something like, okay, don’t trust anything internally, just go to a third party that will know to look at your traffic, see what’s going on, understand when there is this kind of behavioral anomaly, because at the end of the day, that’s what it is. It’s a behavior anomaly and then know how to detect it or to block it, regardless of whether you manage to fix it in your code or not. I think the mixture of both of these protections would help mitigate a very large portion of SSRF, the SSRF attacks and more.

Swapnil Bhartiya: Now, knowing that you are exposed is good, but was again, I want to know from you what advice you have for them so that they can also at least try to protect themselves against such flaws.

Yaniv Balmas: Well, basically it’s exactly what I said. I don’t think there’s anything more than that. I think maybe an additional thing would be to… Because, okay, look at the end of the day, this bug SSRF, as well as any other bug, it always starts with a human error. So there is someone who is coding your software and he made an error somewhere. And quite usually he’s not aware that he made that error, because it’s a very slight error, but in the wrong hands, it could become very dangerous and critical.

So I would say that the third leg, the third thing that could be done is education. Your software engineers, whoever is writing your software with whoever is designing your software, should be aware of the common vulnerability types to say the least and know how to identify them and know how to prevent them before they even present themselves at the code. So just be aware, just educate your software developers. That would be my ultimate suggestion here.

Swapnil Bhartiya: Of course, once you know that you are exposed to the flaw, you have also done things that are there to protect yourself from such flaw. There might still be some gaps that are there. So can you also, once again, share what are the steps that can be taken to remediate any gaps that might be there?

Yaniv Balmas: Well, I think the best approach that I know of would be to not try and understand everything and try to see that I can find anything by defining, “Okay, I’m looking for an SSRF. I’m looking for this thing. I’m looking for that thing.” Because usually that kind of meta method is incomplete. It will never be complete. I think the most effective manner would be behavioral based.

So a website such as anything or web service or anything else should behave in a certain way. If you look at the last million requests that came to your web service or website, the million and one request should practically look the same, it shouldn’t differ a lot from that. If it does differ a lot from that, there is a very high chance that something weird is going on. It might be an attack, it might be something else, but that would be a great and very effective way to try and spot the things that you might have missed in your internal code review or in any other methods.

Swapnil Bhartiya: Now, this is going to be a kind of a higher-level discussion in general about the security. I mean, we live in more or less like a Cloud centric, Cloud native world. We still have those traditional IT flaws, we still do a lot of things OnPrem, but Cloud native is more or less like not a thing, but way of doing things.

So can you talk about, because of this changing landscape where folks are… For digital transformation is happening, folks are moving to a Cloud native kind of processes, with this changing landscape, how is it also changing for financial institutions where security is a different kind of challenge for them? And also of course, once again, we also live in the API driven world, how does API kind of fit into this new reality, where of course the challenge, the risk, the vulnerability, they’re also changing?

Yaniv Balmas: So that’s a great question. First of all, I think that the problem here is not specifically with FinTech, of course, I think with everything, but I think FinTech is a very good example of business sector that’s moving really, really, really quickly towards whatever you said.

So first of all, it’s moving towards being Cloud based and it’s moving towards APIs. The motivation for that is that today, if you are a financial institution, a bank or any other financial institution, if you’re not providing your services online, then maybe today it could still work but looking ahead a few years, I don’t think there would be a lot of businesses doing this same traditional financial approach that we had 5, 10, 15 years ago.

I think that shift comes with two very major flavors. One is the shift to the Cloud. So nobody’s using on-prem anymore. They’re all moving everything to the Cloud. While it might seem to be the same thing. What’s the difference? I mean, if I have the server here right next to me in my server room, or if I have everything in the Cloud, it’s basically the same thing? Generally speaking, yes, it is the same thing, but the devil is always in the details and the nuances count. You can make sure that the tech’ers will know to identify those small places where there is a difference between Cloud and on-prem and we know how to abuse that to their advantage.

Same thing goes for APIs. APIs today are everything they are everywhere. Roughly 80% of all your internet traffic today passes through an API in one way or another. And that’s even bigger in FinTech, because you have the same traditional API transition as with everything else but then within FinTech, there are very large brands like Open Banking and stuff like that, which define the new way of financial institutions talking to each other, talking to the customers. Everything there is based on APIs.

Again, it’s the same thing as in the Cloud. While you might think, “Okay, so what changed, nothing really changed. I’m just using a different method and API there.” But again, the devil is in the details and APIs might be a wonderful thing, but if you don’t pay close attention to these nuances, you might find yourself in a very, very sticky situation. Exactly like the case that we are just talking about right now, it’s a very good use case showing exactly this phenomenon, this thing happening in the real world.

Swapnil Bhartiya: Can you also talk about what Salt Security is doing? What kind of solutions you have to help folks, because once again, as you touched upon earlier, and we know that things are very, very complicated in this Cloud native API driven work and security becomes one more big challenge that you can really… You can lose your whole branding. Forget about a dollar amount. So talk about how you help users and customers.

Yaniv Balmas: Right. So Salt Security does exactly what I said when I talked about behavioral security. We were very smart to identify that several years ago, actually we were the first to identify that and to go into this market and try to create a solution that knows, first of all, it’s a SaaS solution. So it’s Cloud based. It’s very easy integration and you should be able to integrate that into any environment, into any service that’s out there, that’s very important. And once you’ve done that, what our solution does, basically it knows how to study your API traffic in a very smart way.

That could be very challenging if you think about the implementation details of it and the amounts of traffic that we need to deal with, but we figured out how to do that and we do this quite good today. Basically, you just place us at some network protecting some web service or some web services, and we will know how to do exactly that. We will look at the million requests that just came into your service, and then we’ll build some kind of pattern saying, “Okay, that’s how your web service should behave, because most users are legit. They are doing good things.” And then once we see any deviation from this baseline that we just built, then that means that something bad is going on.

If you are smart about it, know how to add a few of these parameters together. You can get to a very fine grained level of alerting of things that are very, very dangerous to you while not alerting on things that might not interest you, because that’s another very important thing. You must keep focused, you can’t just throw a million alerts out there and expect someone to be able to cope with them. You need to provide the smallest amount of alerts that our real wants. And that’s a very big challenge that we’re dealing with and I think we are dealing with it very well.

Swapnil Bhartiya: Yaniv, thank you so much for taking time out today. And of course talk about this SSRF flaw, but in general, what really was incredible was the insights that you shared, or you know organizations can protect themselves and how Salt Security’s helping them. So thanks for sharing all those insights. I would love to have you back on the show, thank you.

Yaniv Balmas: My pleasure, thank you very much.

[/expander_maker]