#SafeSAPUI5 – EP04

[jose_sequeira]

Hello,

*** Default Header ***

With the intention to show why SAPUI5 developers (as most of them came from the ABAP world) need to upskill with “safe programming” knowledge and skills, i’ve decided to create the #SafeSAPUI5.

What is #SafeSAPUI5?

1. A series of episodes with examples (of course with responsible disclosure, not showing names, servers, etc.) of security breaches that were exposed on SAPUI5 apps. The idea here is not to point fingers, but to educate as a “learned mistake” that someone made, to all. I think this is the first series that the creator “hopes” that it has fewer possible episodes ☺️.


2. Encourage developers to also use the hashtag #SafeSAPUI5 around the web on interesting articles, courses (why not?), ebooks or even self made materials, that will help SAPUI5 developers to upskill their knowledge, specially for the security part, also bringing examples that some may had not thought about it.

I try to keep everything as short as possible here, but this researches, analyses, testing, contacting the customers, reporting and getting the bugs fixed takes a long time (not really described here).

SAP has an official bug bounty program, please read more on this link. If you would like to report an SAP vulnerability found, please use the official link here.

*** Default Header ***

Also keeping all the important topics on the matter here: safesapui5.web.app

Ok… So now for the Episode 4 🍿 we have: “Scammers Raw Material...“ ⚠️⚠️⚠️:

🎬

One customer with a custom SAPUI5 application (with internet access, not just inside the customers network), is being used to manage all types of user details. This time i cannot give much details on the scenario, to not disclose the line of business of the customer. This app/Odata services were not that "open", but had just enough information that could be extracted (this time with some effort) to be used on any type os Scams to try go get more info about the user, and then do something real dangerous with it.

Like i sad, informations like: Name, Full Address, ID:

Sensitive Data

Bank ID and Account numbers:

More details

Could be extracted for many users, the IDs used were just to identify the BANK (internet search):

Bank Details

 

Also, there were some "heavy" OData queries, that could easily lead to server problemas (like DOS or DDOs attacks, etc):

Heavy Query...

 

Also, by digging more, even some payments could be found for that IDs:

Earnings

So this time the data leak was not "that" dangerous (of course sensitive data is always dangerous, but comparing to the other episodes), but is just enough for Scammers to contact this users and try to get more data extracted from them.

What types of Scams i'm i talking about? Like the ones that they contact the user with many information about them (like they got from the services above) and pretend that they're the bank, or some company that wants to confirm information. The users may think "If he knows so much about me, then he is probably ho he say he is"...and then provide all the information that he asks (like credit card numbers, passwords, etc.). Always be careful, never disclose information (like passwords, IDs, etc) on the telephone or email, and always asks someone you know for help if you're not sure, before doing anything. To try to understand a little better how the Scammers operate, please check out these youtube channels/videos: Jim Browning,  Kitboga, Scammer Revolts and Scammer Payback.

What happened after that? This time it was just an email and discussion on how to get their app a little more secure and "harder" to display some sensitive information.

Ok, so what can be learned from this episode?

1. On your custom applications, that can be accessed over the internet, all types of researchers (some good, some bad) will be analyzing your application, so please be extra careful with the information that could be found on your $metadata. Also, sensitive type of information cannot be exposed on this open Odata services on the internet, because your Odata services will be tested for possible leaks (like the one found on this episode).


2. Prior to releasing custom SAPUI5 solutions (specially if could be accessed from the internet), conduct all types of testings and validations on all possible scenarios (not just business scenarios, also security scenarios).


3. If your custom SAPUI5 solution is very big/complex, internet faced, and will “contain” all types of sensitive data, you should also consider to work with security researches (for security tests, like myself) or with Bug Bounty programs to stop breaches before the bad guys can find them.


4. Make sure to only allow that specific user (after a login, correctly inside your environment) to see his specific information, not someone else.

PS: Please check episode 03, if you haven’t already.

Thanks.

#SafeSAPUI5