OutSystems Security: TOP 3 Vulnerabilities that are the developer's fault

Should I read what this Lucas Soares guy wrote in this article?

So before we start I want to tell you who Lucas Soares is:

+9 Years of experience in OutSystems

2 Security reports sent to NASA

1 Security reports sent to Apple

1 Creator of the (security) OutSystems Scan Exploit tool

+1 Game developed in Outsystems

+32 Articles published about security in OutSystems

+43 Classes taught at the Rafa OutSystems academy

+29 Projects in OutSystems

+57 OutSystems components in Forge

+7 Mentoring in OutSystems

+15 Security reports sent to OutSystems

I know, I know... you must have thought "WHY WOULD A CRAZY GUY WHO WORKS WITH OUTSYSTEMS SHARE A VULNERABILITY ON THE PLATFORM HE LOVES?".

Answer: Because these vulnerabilities are the DEVELOPER'S fault :)

But I have a better question: Do you like your PET? Your video game? Your clothes? Then you probably take care of them so that they always look good, right? The same applies to other things we love, like children, cars, gifts and others...

Everything we love, we take care of and we will always do our best to make them look good, and the same for me at OutSystems, I love this platform and every time I share an article about OS security, I feel super happy with myself because I know that other developers who also like OutSystems will learn how to build more secure applications and thus I share a subject that adds value to the community.

Okay, introduction done, now let's talk about what matters OUTSYSTEMS SECURITY =)

Hacking is illegal, you can go to jail!        

1 Role Registered

Let's start with a really fun one that "YES" I have done in some projects; you know when we create a screen and configure the roles that can access that screen?! So we often leave the "Registered" role active.

And then we move on to the next application, create more screens and always keep the "registered" role active (even if the other roles are also active, as in the example above).

If you are a technical leader, you already understand where I am going with this... We will have several applications in the client's environment and all of them have the "registered" role active.

This causes the "session misconfiguration" vulnerability or A01 - Broken Access Control. This incorrect configuration allows a demo user or not, authenticated in your application, to access any other application on your site that shares the session (role).

"But Lucas, stop being so dramatic. For this to happen, the hacker must first have a user"... As the layman would say.

Let's look at a real case of this vulnerability where I exploited it, did a proof of concept and sent the results of the vulnerability to OutSystems. Don't worry, OutSystems has already fixed this vulnerability months ago.

Do you see these two applications above? Months ago I reported to OutSystems through a security report that these two applications allowed a hacker to log in through a demo user:

This demo user (Andrea McKenzie) had the "registered" role, so once authenticated with the demo user, I could navigate through other applications that had the "registered" role selected on the screen.

You can see more details of this article here: OutSystems Security: How a demo user gained access to the backoffice.

Hacking is illegal, you can go to jail!        

DISCLAIMER: This vulnerability has already been fixed, keep your OutSystems components and environments updated.

2. Test screens (UsersTest, Login_DEV, etc.)

Sometimes we create test screens because we need to do quick tests, like seeing the result of a query in a production environment, creating an action to delete a specific record to make it easier to clean the database during testing

Things like "GetUsersTest", "TestAPI", "TestScreen" and others... Have you ever done this? Well, I have.

These screens are usually created directly in production, where we cannot debug or get data directly from the aggregates.

The problem with this practice is that these screens usually do not require authentication to access, and sometimes they do not even require a filter to retrieve the data. Simply accessing the screen as an anonymous or registered user (remember the registered role?) is enough to retrieve the content.

Now imagine this in the hands of an attacker. It would be a wealth of information if he found a "TestGetAllTransactions" or "TestAPIGetClients" screen.

OK, you must be thinking "Lucas, if I created the screen and didn't tell anyone, how will a hacker know that this screen exists"?

That's an excellent question and I'll answer it with "OutSystems Scan", which is where I got the screenshot above. Note that it's not only possible to know the test screens in your application but also ALL the screens in your application.

So to avoid this, it's best to set a reminder to delete the test screens in the production environment after using them.

3. Outdated components (Forge)

• When was the last time you checked the components that the development team is implementing in the project?
• Did you know that there are components that use libraries with known vulnerabilities?

I myself have reported vulnerabilities to OutSystems in components that you probably use in some OS project. Do you want some examples? Follow:

CK Editor - Read the article here

UltimatePDF - Read the article here

ECT Provider / Feedback App - Read the article here

Froala Editor (no article)

PDF Viewer - Read the article here

And some others

DISCLAIMER: These vulnerabilities in the components have already been fixed, keep your OutSystems components and environments updated.

Yes, it is possible to view all the dependencies that your application uses, by running just one command line, and in addition, if any component is potentially vulnerable or exploitable, the attacker or hacker will be informed.

But Lucas, I can't remove these components, so what should I do?

A sincere suggestion of some actions that will save you a headache:

• Check if there are any CVE records for the library that your component uses.
• If there is a vulnerability, consider changing the component, because today in Forge there are several alternatives for the same solution.
• Handle all the data input that exists in your application, never trust the "user".
• Perform practical tests, because the library may be vulnerable, but the component runs with low permissions on the OutSystems server and in turn does not pose a danger.

Do you want to talk with me? Visit Soares Corp, I am one of the mentors at OutSystems and I would love to talk to you about security, help with your questions and exchange experiences.

Hug,

Lucas Soares

Here are some other articles where I talk about security in OutSystems:

OutSystems Security: Feedback App (ECT) is extremely vulnerable

Vulnerability in NASA that would be prevented using OutSystems

OutSystems Security: How did a demo user gain access to the backoffice?

OutSystems Security: The vulnerable text editor that empowers hackers, do you use it?

OutSystems Security: How did the user bypass my form validations?

Other sources I used to create this topic:

https://soarescorp.com/

#outsystems #nasa #soarescorp #lucassoares #vulnerability #xss #htmli #corsmissconfiguration #ethicalhacking #ethical #hacking #security #securityresearch