Uncovering SAP BTP Attack Vectors, Before Someone Else Does!

I see that nobody likes SAP topic. Do you you come across SAP? Maybe we can make nice one. >> So we know what SAP is. >> Okay. Does anybody work for SAP? Before I continue. I feel like you work for SAP some. No. A disclaimer. What am I about to say or present? Uh there's definitely a lot of content by SAP that protects all of the things we're going to discuss. This is more towards what companies are moving towards um the the technology that we're using. Um and we're not going to do the old legacy stuff that's still running in most environments. We're just going to see how evolving SAP from what everyone calls a small application into an entire

ecosystem which is quite huge and the attack vector that is there. So yes, SAP does have certain protections um in place for all of the things we're going to discuss here. So we'll come across them later on. Um just a few myths I like to start with SAP because this we usually hear it a lot. um whether it is in Germany or outside of Germany, Europe, it's the global market for SAP. They are um I think they have the biggest share when it comes to ERP um and CRM and so on and so forth. So they do run a lot of different business processes whether it is also industries in manufacturing, airlines, they do have

a lot of areas that they work in but some of them is that we usually hear. So SAP moves with the transformation and the cloud. It's in the cloud so it's protected by default. Um they have a team that makes it protected. So a lot of CISOs we we meet and a lot of CESO I speak to even to some extent people who are outside of this SAP ecosystem or the Japanese world I call it. >> Is it a myth or >> it's a myth? Of course >> that is >> or a misconception. Huh? >> That it's safe and secure. >> Yeah, of course it is. Another one is that identity access management and authorization is the do

it all in SAP. So if you have this secure, you're not going to get um hacked or compromised. Um while this is a big topic in SAP um or in SAP systems, it's still um not the only one. uh you know your your SAP system connects to a lot of different interfaces or a lot of different um nonSAP also applications whether it is banks whether it is um your manufacturing devices there is the nonSAP and SAP systems that operate all of these business processes so quite an important part custom code on SAP is quite heavy we're not going to dig into custom code based off of their um proprietary programming language if anybody have heard of it above

you probably have no so they have a proprietary programming language we'll come to it but also they do have a lot of proprietary network protocols um that enables different communication whether it is between two SAP systems or whether it is with an SAP system to a nonSAP system so um there's that part as well we'll come >> authorization is also a myth >> is >> a myth >> so by itself it is a myth and a misconception that it protects your SCP systems. >> Good to know. >> Why? >> Good to know. >> Okay. Enforcing controls on production also a misconception that so there's these staging levels in SAP you have like any other application development you have

dev you have quality or test and quality and production. All of this is connected to each other. So we do a lot of pent testing in the company and we do find it is very basic mistakes where a um remote function call um also a um proprietary protocol that SAP uses is connected from a quality system to a production with high privileges user and you could use that connection to do a lateral movement. only on production also a misconception to enforce these controls. SAP basis has anybody heard of SAP basis before teams. So they're like your IT administrators, but they're called SAP basis in this Japanese world I call. They take care of configuration. They

take care of setting up everything. They're the best. If you want answers about SAP but not security even though they do handle it in most cases but some organizations are now expanding that specific silo that is there towards the security team who understands threat detection who understands malware who understands all of these specific areas that also apply to SAP. So we try to also another misconception around SAP basis and then the isolation we did speak about different ways that SAP can connected but one of my favorites and of course the last would be is it's German made so it's secure by default you do hear it a lot um um right now you don't as much but yes it's from Germany

it's good software it's isolated um we did apply apply our authorization. So I think it is fine. We don't need to test it. We don't need to look deeper into it. Um but another misconception there. So from an offensive perspective, who does pen testing usually not for SAP? So when you are doing pentesting for SAP, it really depends um on what your target is. Even for the companies that you're doing pentest for. So whether it is on premise, you don't need permission from SAP. Yes. If it's on the cloud, you need permission from SAP. So you need have has anybody recognized this? This is permit 838. Do you know what it is? Has anyone watched Astrix and Olix?

>> What the hell is happening? You moving my slide. Permit 838. Astrix and Oelix had this enormous list of impossible things to do. And this is how you you do a p test also with a but there is a specific note. So there's notes that inform you what you can do for all your system patches. And there's a note specifically for pentesting. And they tell you, all right, you need to go through a process to actually request permissions to do pen testing on their cloud stuff, whether it is a SAS or whether it is um um platform as a service. So BTP what we're going to see now, or whether it's they're hosting it as a hyperscaler or

as a hosting provider, which they are doing right now. So all of this you need um permission to do. You can imagine the process it goes through and they will only give you um unfortunately um a very strict period to do it which is around 5:00 p.m. to after hours 5:00 p.m. to 9:00 p.m. That's what you can do for 2 weeks. Say okay thank you for nothing. So what we did um as as as well outside of the company I created with one of my ex-colagues a um um a OAS project that is related to SAP stuff. I come from a different well my background is not started with SAP but started with sock

and offensive stuff and I wanted to dig deeper into SAP. So, we did create a uh which SAP did not like, but it's okay. A a open-source um pentest playbook that you can find. Um we're still updating it. We're still improving it now. We're going into also um what do you call it? Um BTP sections. Um these are known, another disclaimer, these are known stuff that you can find. We just accumulated it based on certain findings and put it so and then we created this entire project that is also open source that you can do a lot of things with whether it is creating rogue application servers with the honey SAP or really um crafting packets based on those

proprietary protocols using PYP. It's built on top of Scappy and also provides you with ways that you can really um attack an SAP system responsibly. Another disclaimer anyway attack service discovery. So there are different pieces we're introducing more and this is for um the the the open source community. is on the OASP um project and we try to bring it from a perspective that people who do not know SAP and want to test or want to let's say put it out or understand it from their organization this is where is definitely a a big part now we do a lot of um um open source stuff so the more the marrier that can help we're around now 70 plus people

that are working on this and hopefully we can get some more people to do the contribution. But about me, so I'm Wasim. I work at No Monkey as as Rita was saying. We specialize I think you guys got it. Specialize in SAP cyber security. So whether it is from detection to pentesting to teaching about those different areas to soft teams to cyber security teams, we provide that. My background comes from the cyber security and bringing that into SAP makes it a bit different than somebody who has been in SAP for a very long time going out of but we have that mix within the team which is always great to have. All right, we're going to start a little

bit with this vector. I know that some of this is new to all of you. I'll try to explain as much as I can um with the time that we have but we'll try to identify. So what you have here you have three different environments. You have your on premise what most of the organizations would have definitely and a whole bunch of application servers. So these application servers serve for different business processes whether it's your finance HR you name it it is there and what they introduced is everybody needs to move to the cloud. So you have your private cloud environment whether you're hosting it on JCP or you're hosting it on AWS but also you

can host it with SAP for added security as they say. So um there's that part. So you have to I think there's some now um um limit or time where on premise has to completely shift to the private cloud. While it's very difficult with bigger older companies within Germany and outside of Germany, um this is their goal until 20, it was 2027 and now it's 2030. I don't know how that's going to work. But then they have this uh platform as a service which is the BTP and what it introduces is yes you can connect to your on premise you can connect to your private cloud environment your public cloud environment but also you can

connect to other applications within your environment whether it is open and not so open source sorry um non SAP applications SAP applications HR systems I don't know if you've heard of success factors for HR these kind of applications you and connect and to connect to that and then try to connect it also to your on premise and this is the use of what is called a cloud connector. You could think of it as a router not a router a bit more glorified than a router and it enables this kind of connection from BTP to your on premise. So this is the single point of entry for your onremise. I let you uh get that synced in. So this

is your single point and with what SAP states is that you don't need a firewall here for a cloud connector because it's a one-way communication and it is it starts um creating an encrypted tunnel where you it only starts or the tunnel starts once a command or a request goes from the on premise. So and this is the core of our research where this is not the case. This is where we've identified that you can jump from a own custom application from here going into the on premise using this secure tunnel that SAP has created and we shall see it together but at least you get an idea of the ecos well it's not the full picture

but this is more towards what we have been um researching we do a lot towards also the on-remise part. Um, but that's a different conversation. So, BTP, we just said it, it's more towards or at least offers integration environments that you can build your own applications, analytics, you name it. It's a platform as a service. Everything that you find here, you will find in those other hyperscalers. Um but this is more also towards enabling those customers to stay with SAP of course and move from this on premise excuse me to the cloud environ. All right excuse me I'll let you read it while I drink water. So I just want to explain how the architecture works

so my demo would make sense because then it wouldn't make sense. So with BTP every company who um subscribes or or gets a a a BTP account, they get one global account. It's just your subscription or your um entitlement towards SAP. It's your contract. This is a global account and then you could start creating multiple sub accounts and this sub accounts then you have your services whatever you're doing um authentication services you name it and then runtimes runtimes are your environments that enables you to build your own custom applications. So the main introduction of those runtimes is also to remove or to get away from above their programming um area. As you might notice like cloud foundry is open

source. So you probably have come across cloud foundry before. You could put this not just in SAP but in any other system and run it your own machine. KMA is heavily supported by SAP um and it works on Kubernetes. So if you know Kubernetes, you know Ka but we'll come later to this. To expand this diagram a little bit from here to here so you could get an understanding of what you might find. You will find your cloud connected. Of course, as I said before, you're on premise going into the global account. But before that, you probably would need a identity provisioning service or an authentication service. SAP has their own products, but you can

use Microsoft or other provisioning services to connect. Um, you just need to utilize proper APIs and you can do it. That's not a problem. And then within these sub accounts, so they have also the staging stuff, production sub accounts, development sub accounts and so on and so forth. And it still becomes the same mentality you were thinking of in on premise with all the different services, the environments that you have. This enables it at least to um identify or build what you require for your on-remise for your um open services for your nonSAP systems but it helps organize certain stuff. So you can imagine that security requirements would definitely start regardless of that from your global account. How you are doing

your directories against sub accounts uh what you're doing with with identity access management your interfaces what they can access and so on and so forth. So this is just a different architecture on how these directories work. So this is the global account. You can have multiple sub accounts and then you could see and imagine how your attack vector can grow from here. Now this is the same well not mentality but same sort of um um design that was also in the on premise. you have an application server that can be um multiplied or expanded through instances and thus you have the same kind of concept with these global accounts or with BTP in general. So the

more that you have the more you need to really look into it and this is where the attack vector starts to grow from that perspective. I did speak about environments but these are the most um ones that are used. Yes, they brought AB up. I did say that they wanted to get rid of it but that is impossible with with their onremise stuff or with especially older companies that have older bigger companies that have these legacy R3 or their older SAP systems they still need AB for their custom coding. But this is when you're shifting or when you are um developing definitely there's a lot of ways that you can protect it. It's not that it

doesn't provide those functionalities but they wanted to introduce it. So their entire kind of concept of we want to get rid of ABAB did not quite work as they wanted. But also the attack or the vector has expanded with the use of other programming languages whether it is around what you can do in cloud foundry or what you can do in KA. So now you could use anything that you can imagine. So our attack vector involves cloud foundry. um this is bunch of I don't need to explain all of this we can come back to it but what is the attack vector so usually this is actually we took it as an example from one of our findings

um you have a normal human connecting to an application that is built on this environment or on this cloud foundry um and then you need to provide what SAP calls a destination service So it's basically a route that tells this application any kind of requests that is coming from this user let them um get some information from this internal back end or this database or whatever you are having there and starting exchanging. So it's basically a router a um I don't know even if that makes sense with the destination service but it provides users with where they need to go. You can put authentication, you could put authorizations on it, you could block certain traffic if properly

done. So what we've identified is that usually with those apps that are being developed, developers forget to close down certain services and certain uh backend information like secret keys, like private keys, like certificates. And this is a configuration issue. This is not like wow, what did you find? No, this is a configuration issue that we like it's identified um every time we go in there and then after that you are directly will be able to speak from the client or send requests directly to your back end which shouldn't be publicly available or shouldn't be publicly yeah available from that puh perspective. So, I'm going to play the demo. Unfortunately, um I wanted to do this as

a um live, but SAP blocked my account a month ago. It's not about any kind of security perspective, I think. So, I don't know. Um we have a paid uh environment that we play around with, but I'm not sure what happened, but they did block it. So, you get the demo. We actually did we presented this in in Bside Reson. Um luckily I found one of the demos. The other one unfortunately is not there but I will explain the attack vector from the KMA environment. So just a a quick um attack chain or the heist of of this cloud foundary. We're going to find some services that shouldn't be there. And this we just replicated a application we

have been working on from um a customer and then we tried to steal some certificates try to look for this is like you're going to see like okay this is nothing easy to do and then finding those services apps.in internal and then directly starting having access to customers or financial information um from that perspective. Let's see if that works. So here is your normal flask app. It's quite vulnerable. So um um we're just trying to identify what happens. And then you need to really um define different services. So whether it is the authentication access which is UAA or user authentication user access and authentication that provides you with the access that is required to actually

go into that application. those specific services you need to create. Just uh to show you that we will go to the BTP actually, but here there are four applications running. The demo is the one that is published. The internal back end is the one that shouldn't be published. We're going to find a way to get that through those um um see what kind of services are published. But in general um just information on the application you could SSH into Cloud Foundry instances that you create and they're called spaces in Cloud Foundry just as an FYI. Um and these spaces enables you yeah to develop anything. So this is just a view of what you could

see in BTP. These are our research um demos of applications. This is from front end. you could control it everything here put all your different configuration security stuff around this um going into the demo or the RC demo also you could understand the instances that are running what kind of capacity so on and so forth um I'd like to skip it but we have to wait because I'm not running up there and then you find the routes this is where you're I talked about the destination services so um the BTP we have the internal back and where it's supposed to go for every request. Um what you can do with it um and the path

of course the domain that is there but at least you could get an idea of what needs to uh work for every request that is coming. So we're going to take this domain for the public available services put it on webuite. Yeah it's quite easy. it's not a um and then try to identify those services. As you can see these services that we identified was a service called command run and then a debug environment. I mean anybody who's done pen testing or a security person who just has some logic would say okay so the command run must be that we can access something in the back end. But was it the internal back end or the

front end which is the demo? It was the front end which is okay because with these services how they are designed is to um protect or save secrets inside the coding application. So you're connected to this back end but every secret is um saved in the initial application or in the published application. We'll have a look. We're just now just testing this command run with who am I? And then you could see the user which is it's a it's a pretty um lowlevel privileged user that can't do much um but that user can read instance keys can read then certificates. So this is actually the private key and can read certificates. So that normal privileged user or not

non-privileged user as they say and again you could read the certificates from that perspective. So what else can we find that enables us to really go into the back end um yeah we just have to wait a little bit um to see from the instance or the debug environment. This is usually all of this can be restricted. So you can put authentication around it. you can not publish it. And now we're going to test out this service that is called debug environment or debug env. And from there you could find then um from here the the client ID you have some secrets for the UAA um the instances. Uh you can find a bunch of random information about

certain variables. Um the most important part of course um where is this connecting to like what kind of backend services are we looking for and this is also available in these kinds of configuration which is the the VCAP services here and it just tells you okay this um publish available application is connecting to a PTP internal back end with a secret name that is there. So this was actually a an actual instance that we allocated. So this is the uh just going to the demo. I think we need to go this is the binding where you can create all of this. It's just showing where you could do it and how you can protect it properly. But this wasn't the

case when you are creating those bindings to connect your published application into your internal application. There's a credential store which is shown inside the cloud foundar space and this is what you see here. So by default now um you would want to test how you can reach this internal backend instance. All you need to do is get this um um URL or the target and we try to request what kind of stuff we require. Do we need a username password? Do we need an API key? And apparently it just needed to get that API key that is shared to the front end, pass it along and get the information we require. So bear with me a few seconds

to showcase that. And we're changing the target now.

and then of course you're not allowed once that is changed you're not allowed you need some sort of um authentication or you need that X API key and you take that like the developer was quite um um helpful in telling us what you require for a request. Then once you gather that you found that X API key um inside one of the environmental variables, you just need to request it and request the customers that is there renew it from and then you get a whole bunch of information around that. not difficult, not super difficult but um also very interesting on misconfiguration and authentication when it happens but also with how uh the concept of the sub accounts and global

accounts where you need to put these kinds of security measures in place. I did say SSH previously and this service was quite also interesting. Anybody who has access to this space or where you are creating applications can easily um create a one-time password which is created by um as a functionality. I don't know why. I'm happy to hear your thoughts. A one-time password to access the SSH service. So you could if you have a space you could click I need a onetime password. You get it you access SSH. Now the tricky part is even if you have disabled SSH on your production sub accounts you need to actually disable it from the entire global account because

that does then you still running still working how the connection from these environments to the services there's an SSH running you could connect to it so that's a different demo of course but um it's quite interesting if you come across any kind of cloud foundary services look for an SSH it's not on port 2022. It's 2222 something like this where you could find this SSH ka similar concept I don't have the demo for this unfortunately but Kubernetes anyone worked with Kubernetes before okay good so it has it's basically based off of the Kubernetes SAP supports this heavily it's quite good you just need to protect it so what the attack vector um has enabled us to do is you have a

similar thing. you have a client um there's a gateway for within KMA there's different runtimes and you have your applications then you have this connectivity service uh we did say there's a destination service and connectivity service is allows you to connect to your on premise we mentioned the cloud connector it is a oneway um traffic one way it's a tunnel that is created between your BTP and on premise and the only way and I'm just repeating SAP's words. The only way that it starts a interaction is by sending a request from here, not from the BTP. So, how can we see if this is an actual risk? Um, what we've identified is that cloud connected um publishes services from

your on premise and those services just it's the same thing as as your cloud foundry. it is for your um applications, for your customers, for whatever you're using these services for. It helps you um or if you have it published, you take these services, you conduct similar things that you have conducted in your cloud foundry. The only thing that you only need to change is how to do a lateral move toward your on premise. And if you remember, I said that SAP uses their own proprietary protocols called RFC, remote function calls. And this is the best way to do it. They're very powerful. Remote function calls use uh function modules and these function modules is

just a bit of code to tell the system what to do. And SAP has over, I would say over 90,000 plus function modules. This is where most of the research, just FYI, side note, um goes into these function modules because it's a bunch of code that's quite vulnerable. You can stop it, you can block it, you could do whatever you want from it. But once you have it, then you could utilize this um kind of pivoting towards your on premise with function module. So SAP would look at it like, oh, it's my own proprietary protocol. I'm going to use it and you user can use it as well because I trust you. This default trust in SAP technology is

quite um phenomenal I would say and it happens also on premise. So they have this default trust. They're trying to improve to be honest with you. Um and a lot of companies are moving from okay if it's an SAP system um then I don't need to trust it right away because we've introduced this rogue application servers that then it's direct trust that you can register to an application server. So this is the same way or mentality of thinking about it um and then the cloud connector was not needed if I roll in front of it for these kind of requests. All right, SAP best practices. Um, that's it. No. Um, there's a lot of best

practices from that perspective. So, please go ahead and read. There's a lot to do. Um, definitely they will not with cloud cloud um foundry. It's open source. So it's not just SAP telling you what you can do but go to the cloud foundry um um portal or whatever it is to also identify what you are able to do from there or KMA as well with ABBA. Oh that's even a different talk and different discussion which um if you want to discuss it please find me later. All right you saw it. Yes. Anyway, what I do and I enjoy my work is protecting this. I know that and and we are in one of the most consume uh

um country cities, countries that consume beer a lot. So imagine and it does operate. So 72% of the world production depends on SAP. Of course, airports, airlines, whatever you call it, depend on SAP. Um, but imagine these empty halls or October Fest if you've ever visited and it would be empty. So this is why I do it. Why I went into this Japanese world? Not really, but it's a benefit for me that I I try to protect this or the company. There's a lot of stuff that are happening around SAP security. So SAP does um um provide that kind of protection. It's just up to the customer to do it. So they provide a lot of

documentation. SAP is not a security company. It's a application whatever you want to call it company ERP CRM. So security is provided. It's just the customer needs to do it or the organization utilizing SAP needs to do it. The information is kind of scattered everywhere. Um that's why we are do what we do. But at least from that perspective, um I even can save you some time. Uh what we do with SAP security. I hope that was um informative. If there's any questions, please. Thank you very much.

Have you found any sub accounts issues? >> Sorry again. >> Have you found any gross sub accounts issues? Like there's the whole concept having global accounts and sub accounts. So have you found something or identify something that be like cross sub account >> gross sub account. Um maybe I like cross sub account >> cross sub account cross. Okay my bad. Yes. Uh with those environments. So these environments can enable you to utilize certain sub accounts. Now yes there is some sort of isolation but when you are working with environments that you are working to some extent on a different um I'm not going to call like on a different infrastructure than the actual BTP that's sitting on. So yes

there is a way to do it. We have not identified but we have identified that you can actually um see other sub accounts to some extent which would be interesting to see if you can get into it right still there's to to like with the research there's a lot of limited stuff that you can do that SAP still needs to know about right even if it is like our own accounts and our own platform um you still need to inform or maybe they blocked my account because of that. I don't know. But um it's actually the entire company's account is blocked. I don't know if it's because of me, but anyway. Um um yeah, there's there's a lot to do.

You have to be in touch with SAP a lot. They would allow you to some extent depending on how far you go with that. Um and we always are reporting these um responsibly. Um but yeah, thank you. Thank you very much.